You create a host key for the SSH server with the crypto key generate dss command. If a host key already exists, this command replaces it with a new key and terminates all ongoing SSH sessions. Any SSH clients that previously accepted the old host key reject the new key the next time the client and server connect. The client then typically instructs the end user to delete the locally cached host key and to try to connect again.
![]() |
Caution: Use caution issuing the crypto key generate dss command from an SSH client. Issuing this command will terminate that SSH session; it will be the last command you send from that session. |
The public half of the host key is sent from the server to the client as part of the transport layer negotiation. The client attempts to find a match for this key with one stored locally and assigned to the server. If the client does not find a match, it can accept or reject the key sent from the server. Refer to your client documentation for detailed information. You typically configure the client to do one of the following:
If you do not want the client ever to trust the server when it sends an unknown key, you must manually copy—using the copy command—the host key from each server to each intended client. This is the only way to be certain that each client has a local copy of the necessary keys for matching during negotiation.
If you configure the client to accept unknown keys—either automatically or with administrator approval—this acceptance policy applies only to the first time the client receives a key from a particular server. When the SSH client accepts a host key, it stores the key locally and uses it for all future comparisons with keys received from that host. If the client subsequently receives a different key—a new unknown—from that server, it is rejected.
You cannot configure an SSH client to accept a new key after it has accepted a key from an SSH server. You must delete the old key before a new key can be accepted.