Visual RFC.
ALL RFCs / RFC 4251
Read the RFC ↗
RFC 4251 / MECHANISMS

Host keys identify the server

02

The client needs a trustworthy binding between a server name and its host key.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 4.1 ↗
RFC 4251 · § 4.1EXAMPLE
3 / 3
Host keys identify the serverThe client needs a trustworthy binding between a server name and its host key. Current state: Changed key.Host keys identify the serverknown_hostsserver.example → key Apresented key Bcomparechanged key: investigate
03
Changed key

A mismatch demands investigation; silently accepting it defeats the check.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

A host-key signature alone does not establish the intended server name.

  • A host-key signature alone does not establish the intended server name.
  • A local host-key database or a trusted certification system can provide the binding.
  • First-use acceptance without independent verification leaves an active-attack risk.
DETAILS

The illustration is schematic. Example values are illustrative; profiles and later security guidance can add requirements.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Three layers have different jobs
  2. Host keys identify the server
  3. An unchecked key enables a middleman
  4. One transport carries channels
  5. Security has endpoint limits

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗