the client host is checked more rigorously.
This method works by having the client send a signature created with
the private key of the client host, which the server checks with that
host’s public key. Once the client host’s identity is established,
authorization (but no further authentication) is performed based on
the user names on the server and the client, and the client host
name.
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "hostbased"
string public key algorithm for host key
string public host key and certificates for client host
string client host name expressed as the FQDN in US-ASCII
string user name on the client host in ISO-10646 UTF-8 encoding
[RFC3629]
string signature
Public key algorithm names for use in ’public key algorithm for host
key’ are defined in the transport layer specification [SSH-TRANS].
The ’public host key and certificates for client host’ may include
certificates.
The value of ’signature’ is a signature with the private host key of
the following data, in this order:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "hostbased"
string public key algorithm for host key
string public host key and certificates for client host
string client host name expressed as the FQDN in US-ASCII
string user name on the client host in ISO-10646 UTF-8 encoding
[RFC3629]
The server MUST verify that the host key actually belongs to the
client host named in the message, that the given user on that host is
allowed to log in, and that the ’signature’ value is a valid
signature on the appropriate value by the given host key. The server
MAY ignore the client ’user name’, if it wants to authenticate only
the client host.
Whenever possible, it is RECOMMENDED that the server perform
additional checks to verify that the network address obtained from
the (untrusted) network matches the given client host name. This
makes exploiting compromised host keys more difficult. Note that
this may require special handling for connections coming through a
firewall.
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-CONNECT], and
this document, are detailed in [SSH-NUMBERS].
11. Security Considerations
The purpose of this protocol is to perform client user
authentication. It assumed that this runs over a secure transport
layer protocol, which has already authenticated the server machine,
established an encrypted communications channel, and computed a
unique session identifier for this session. The transport layer
provides forward secrecy for password authentication and other
methods that rely on secret data.
Full security considerations for this protocol are provided in
[SSH-ARCH].
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-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006.
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, 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.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
12.2. Informative References
[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).