authenticate the key exchange. The exchange hash SHOULD be kept
secret.
The signature algorithm MUST be applied over H, not the original
data. Most signature algorithms include hashing and additional
padding (e.g., "ssh-dss" specifies SHA-1 hashing). In that case, the
data is first hashed with HASH to compute H, and H is then hashed
with SHA-1 as part of the signing operation.
8.1. diffie-hellman-group1-sha1
The "diffie-hellman-group1-sha1" method specifies the Diffie-Hellman
key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024-
bit MODP Group). This method MUST be supported for interoperability
as all of the known implementations currently support it. Note that
this method is named using the phrase "group1", even though it
specifies the use of Oakley Group 2.
8.2. diffie-hellman-group14-sha1
The "diffie-hellman-group14-sha1" method specifies a Diffie-Hellman
key exchange with SHA-1 as HASH and Oakley Group 14 [RFC3526] (2048-
bit MODP Group), and it MUST also be supported.
9. Key Re-Exchange
Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when
not already doing a key exchange (as described in Section 7.1). When
this message is received, a party MUST respond with its own
SSH_MSG_KEXINIT message, except when the received SSH_MSG_KEXINIT
already was a reply. Either party MAY initiate the re-exchange, but
roles MUST NOT be changed (i.e., the server remains the server, and
the client remains the client).
Key re-exchange is performed using whatever encryption was in effect
when the exchange was started. Encryption, compression, and MAC
methods are not changed before a new SSH_MSG_NEWKEYS is sent after
the key exchange (as in the initial key exchange). Re-exchange is
processed identically to the initial key exchange, except for the
session identifier that will remain unchanged. It is permissible to
change some or all of the algorithms during the re-exchange. Host
keys can also change. All keys and initialization vectors are
recomputed after the exchange. Compression and encryption contexts
are reset.
It is RECOMMENDED that the keys be changed after each gigabyte of
transmitted data or after each hour of connection time, whichever
comes sooner. However, since the re-exchange is a public key
operation, it requires a fair amount of processing power and should
not be performed too often.
More application data may be sent after the SSH_MSG_NEWKEYS packet
has been sent; key exchange does not affect the protocols that lie
above the SSH transport layer.
10. Service Request
After the key exchange, the client requests a service. The service
is identified by a name. The format of names and procedures for
defining new names are defined in [SSH-ARCH] and [SSH-NUMBERS].
Currently, the following names have been reserved:
ssh-userauth
ssh-connection
Similar local naming policy is applied to the service names, as is
applied to the algorithm names. A local service should use the
PRIVATE USE syntax of "servicename@domain".
byte SSH_MSG_SERVICE_REQUEST
string service name
If the server rejects the service request, it SHOULD send an
appropriate SSH_MSG_DISCONNECT message and MUST disconnect.
When the service starts, it may have access to the session identifier
generated during the key exchange.
If the server supports the service (and permits the client to use
it), it MUST respond with the following:
byte SSH_MSG_SERVICE_ACCEPT
string service name
Message numbers used by services should be in the area reserved for
them (see [SSH-ARCH] and [SSH-NUMBERS]). The transport level will
continue to process its own messages.
Note that after a key exchange with implicit server authentication,
the client MUST wait for a response to its service request message
before sending any further data.
11. Additional Messages
Either party may send any of the following messages at any time.
11.1. Disconnection Message
byte SSH_MSG_DISCONNECT
uint32 reason code
string description in ISO-10646 UTF-8 encoding [RFC3629]
string language tag [RFC3066]
This message causes immediate termination of the connection. All
implementations MUST be able to process this message; they SHOULD be
able to send this message.
The sender MUST NOT send or receive any data after this message, and
the recipient MUST NOT accept any data after receiving this message.
The Disconnection Message ’description’ string gives a more specific
explanation in a human-readable form. The Disconnection Message
’reason code’ gives the reason in a more machine-readable format
(suitable for localization), and can have the values as displayed in
the table below. Note that the decimal representation is displayed
in this table for readability, but the values are actually uint32
values.
Symbolic name reason code
------------- -----------
SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
SSH_DISCONNECT_PROTOCOL_ERROR 2
SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
SSH_DISCONNECT_RESERVED 4
SSH_DISCONNECT_MAC_ERROR 5
SSH_DISCONNECT_COMPRESSION_ERROR 6
SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
SSH_DISCONNECT_CONNECTION_LOST 10
SSH_DISCONNECT_BY_APPLICATION 11
SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12
SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13
SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14
SSH_DISCONNECT_ILLEGAL_USER_NAME 15
If the ’description’ string is displayed, the control character
filtering discussed in [SSH-ARCH] should be used to avoid attacks by
sending terminal control characters.
Requests for assignments of new Disconnection Message ’reason code’
values (and associated ’description’ text) in the range of 0x00000010
to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
described in [RFC2434]. The Disconnection Message ’reason code’
values in the range of 0xFE000000 through 0xFFFFFFFF are reserved for
PRIVATE USE. As noted, the actual instructions to the IANA are in
[SSH-NUMBERS].
11.2. Ignored Data Message
byte SSH_MSG_IGNORE
string data
All implementations MUST understand (and ignore) this message at any
time (after receiving the identification string). No implementation
is required to send them. This message can be used as an additional
protection measure against advanced traffic analysis techniques.
11.3. Debug Message
byte SSH_MSG_DEBUG
boolean always_display
string message in ISO-10646 UTF-8 encoding [RFC3629]
string language tag [RFC3066]
All implementations MUST understand this message, but they are
allowed to ignore it. This message is used to transmit information
that may help debugging. If ’always_display’ is TRUE, the message
SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless
debugging information has been explicitly requested by the user.
The ’message’ doesn’t need to contain a newline. It is, however,
allowed to consist of multiple lines separated by CRLF (Carriage
Return - Line Feed) pairs.
If the ’message’ string is displayed, the terminal control character
filtering discussed in [SSH-ARCH] should be used to avoid attacks by
sending terminal control characters.
11.4. Reserved Messages
An implementation MUST respond to all unrecognized messages with an
SSH_MSG_UNIMPLEMENTED message in the order in which the messages were
received. Such messages MUST be otherwise ignored. Later protocol
versions may define other meanings for these message types.
byte SSH_MSG_UNIMPLEMENTED
uint32 packet sequence number of rejected message
12. Summary of Message Numbers
The following is a summary of messages and their associated message
number.
SSH_MSG_DISCONNECT 1
SSH_MSG_IGNORE 2
SSH_MSG_UNIMPLEMENTED 3
SSH_MSG_DEBUG 4
SSH_MSG_SERVICE_REQUEST 5
SSH_MSG_SERVICE_ACCEPT 6
SSH_MSG_KEXINIT 20
SSH_MSG_NEWKEYS 21
Note that numbers 30-49 are used for kex packets. Different kex
methods may reuse message numbers in this range.
13. IANA Considerations
This document is part of a set. The IANA considerations for the SSH
protocol as defined in [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT], and
this document, are detailed in [SSH-NUMBERS].
14. Security Considerations
This protocol provides a secure encrypted channel over an insecure
network. It performs server host authentication, key exchange,
encryption, and integrity protection. It also derives a unique
session ID that may be used by higher-level protocols.
Full security considerations for this protocol are provided in
[SSH-ARCH].
15. References
15.1. Normative References
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Authentication Protocol", RFC 4252, January
2006.
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Connection Protocol", RFC 4254, January 2006.
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell
(SSH) Protocol Assigned Numbers", RFC 4250, January
2006.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
1321, April 1992.
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R.
Thayer, "OpenPGP Message Format", RFC 2440, November
1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
(MODP) Diffie-Hellman groups for Internet Key Exchange
(IKE)", RFC 3526, May 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[FIPS-180-2] US National Institute of Standards and Technology,
"Secure Hash Standard (SHS)", Federal Information
Processing Standards Publication 180-2, August 2002.
[FIPS-186-2] US National Institute of Standards and Technology,
"Digital Signature Standard (DSS)", Federal
Information Processing Standards Publication 186-2,
January 2000.
[FIPS-197] US National Institute of Standards and Technology,
"Advanced Encryption Standard (AES)", Federal
Information Processing Standards Publication 197,
November 2001.
[FIPS-46-3] US National Institute of Standards and Technology,
"Data Encryption Standard (DES)", Federal Information
Processing Standards Publication 46-3, October 1999.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols algorithms and source in code in C", John
Wiley and Sons, New York, NY, 1996.
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
128-Bit Block Cipher, 1st Edition", March 1999.
15.2. Informative References
[RFC0894] Hornig, C., "Standard for the transmission of IP
datagrams over Ethernet networks", STD 41, RFC 894,
April 1984.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[ssh-1.2.30] Ylonen, T., "ssh-1.2.30/RFC", File within compressed
tarball ftp://ftp.funet.fi/pub/unix/security/
login/ssh/ssh-1.2.30.tar.gz, November 1995.
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.
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).