System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

PDF

System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

SSH client strict host key checks

Want to summarize with AI?

Log in

Describes SSH client strict host key checking and explains how this feature enhances security and compliance on Cisco IOS XR routers by enforcing validation of server host keys before establishing SSH connections.


A SSH client strict host key checking is a feature that

  • enforces validation of server host keys using a system-wide known_hosts file,

  • restricts SSH client connections to hosts with trusted or previously accepted host keys, and

  • supports configurable policies for new or changed keys, such as off, accept-new, ask, or yes.

The knownhosts file is located at /mnt/rdsfs/ciscossh/known_hosts and is shared across all users, providing persistent, centralized host key management for SSH client operations.

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

SSH client strict host key checking

Release 26.3.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q200, P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8600 [ASIC: Q200], 8400 [ASIC: K100]); Modular Systems (8800 [LC ASIC: Q200, P100]).

You enhance SSH security by enforcing strict host key checking, allowing you to control how the SSH client handles new or changed server keys - accept, reject, or prompt for approval. Trusted host keys are stored system-wide and persist across reloads, ensuring consistent validation for your outbound SSH connections.

Note

SSH client strict host key checking is incompatible with the legacy ssh client knownhost configuration. Remove the legacy configuration before configuring strict host key checking or using the ssh-client knownhosts exec-mode commands.


Restrictions for SSH client strict host key check

Provides reference information about the modes of SSH client strict host key checking, their behaviors, and their effect on host key storage, automation, and system security.

  • All SSH client users share the default known hosts file at /mnt/rdsfs/ciscossh/known_hosts. Adding, deleting, or accepting a host key in this file affects all SSH client sessions.

  • RDSFS must be available to retain host keys across device reloads and switchovers.

  • When you use the ssh-client knownhosts import <file-path> command, the imported file replaces the contents of the default known-hosts file. The system does not append the imported entries.

  • Host keys learned through SSH, SCP, SFTP, or other CLI operations that initiate SSH, SCP, or SFTP sessions are stored only in the default system-wide knownhosts file.

  • The following strict host key checking modes are available:

    • strict-check off: Automatically accepts new or changed host keys. This mode weakens protection against man-in-the-middle attacks and should be used only for temporary, low-risk troubleshooting.

    • strict-check accept-new: Automatically accepts and stores new host keys, but rejects changed host keys.

    • strict-check ask: Prompts for approval only when an unknown host key is encountered. After the key is accepted and stored, any later change to that host key is rejected.

    • strict-check yes: Rejects both unknown and changed host keys. To avoid connection failures, pre-populate the trusted host list before enabling this policy.

    Note
    If the legacy ssh client knownhost command is present in the global configuration, you cannot configure strict-hostkey-check. The exec-mode ssh-client knownhosts commands are also unavailable until you remove the legacy configuration.

SSH client knownhosts commands

The trusted-host database is stored in /mnt/rdsfs/ciscossh/known_hosts and is shared by all SSH client users.

Use these commands to manage entries in the trusted-host database.

Table 2. SSH client known hosts commands

Command

Description

ssh-client knownhosts add

Adds a trusted-host entry.

ssh-client knownhosts import

Imports a knownhosts file.

ssh-client knownhosts export

Exports the trusted-host database.

ssh-client knownhosts delete hostname

Deletes an entry by hostname.

ssh-client knownhosts delete line

Deletes a numbered entry.

ssh-client knownhosts clear

Removes all entries.

show ssh client knownhosts

Displays the trusted-host entries.

Run these commands in exec mode.

Host keys learned during SSH, SCP, SFTP, or another CLI session are stored only in the system-wide database.


Configure SSH client strict host key checking

Configure SSH client strict host key checking to control how routers verify SSH server host keys for outbound SSH connections and prevent unauthorized access.

  • Enforce trust of only verified SSH servers to meet security policies.

  • Minimize operational risk by ensuring host trust decisions are policy-driven.

Note

The global strict host key checking configuration can be overridden for an individual SSH, SCP, or SFTP session using the strict-hostkey-check option.

SSH client strict host key checking validates remote server keys before starting an SSH session. All SSH client operations reference a single, system-wide knownhosts file at /mnt/rdsfs/ciscossh/known_hosts, regardless of the user.

This mechanism ensures that clients only connect to trusted hosts and enables administrators to choose the level of enforcement (off , accept-new , ask , or yes ) for their environment.

  • No per-user host key management; changes are global for all SSH client users.

  • The strict-check mode controls the degree of host verification and is set according to deployment security requirements.

Before you begin

  • Administrative access to the Cisco router.

  • Persistent storage is available and RDSFS is mounted at /mnt/rdsfs.

  • Your organization's SSH security policies for trusted host validation are known.

Follow these steps to configure SSH client strict host key checking.

Procedure

  1. Set the SSH client strict host key checking mode.

    Example:

    Router# configure
    Router(config)# ssh client strict-hostkey-check {off | accept-new | ask | yes}
    Router(config)# commit
    • off: Automatically accepts new and changed host keys.

    • accept-new: Accepts and stores new host keys, but rejects changed host keys.

    • ask: Prompts for an unknown host key; after it is accepted and stored, rejects any later key change.

    • yes: Rejects both unknown and changed host keys.

  2. Exit configuration mode.

    Example:

    Router(config)# end
  3. For an individual node, use exec-mode commands to manage trusted-host entries.

    The following commands operate on the current node. To align trusted-host entries across nodes, copy and import the same baseline known-hosts file on each node.

    1. Import a baseline knownhosts file.

      Example:

      Router# ssh-client knownhosts import <file-path>
    2. Export the system-wide known-hosts database.

      Example:

      Router# ssh-client knownhosts export <file-path>
    3. Add, delete, or clear trusted-host entries if required.

      Example:

      Router# ssh-client knownhosts add
      Router# ssh-client knownhosts delete hostname
      Router# ssh-client knownhosts delete line
      Router# ssh-client knownhosts clear

      To manage the trusted host entries, see SSH client knownhosts commands.

  4. Verify the trusted-host list.

    Example:

    Router# show ssh client knownhosts

SSH client strict host key checking is configured. The router handles new and changed SSH server keys according to the selected enforcement mode.

What to do next

Review the router's outbound SSH connection logs to confirm that SSH client connections are handled according to the selected strict host-key checking mode and your organization's SSH security policies.