Host authenticity check [LWN.net]

Host authenticity check

Posted Feb 16, 2007 23:55 UTC (Fri) by ldo (subscriber, #40946)
Parent article: Set up remote access in UNIX through OpenSSH (developerWorks)

The article mentions the "authenticity of host <blah> can't be established" warning, but implies that you simply have to put up with it the first time you connect to a new host.

In fact, ignoring this warning and typing "yes" to proceed leaves you open to the chance of a host-spoofing attack. The right way to deal with this is one of:

You (or somebody) previously did the following command on that host:
ssh-keygen -l -f /etc/ssh/ssh_host_key.pub
and saved the output so you can compare the host key fingerprint with that from the warning, to ensure they're the same. Or,
You previously grabbed a copy of the entire /etc/ssh/ssh_host_key.pub file, so you can manually insert it into your ~/.ssh/known_hosts file and avoid the warning altogether.

The article says you will get another "warning" if the host key changes. In fact, in the default SSH configuration, this is not a warning, this is an error, and it will not let you connect to the host. This is a Good Thing, as there should never be any reason for the host key to change. (When I install a new Linux version on a machine, one of the things I'm careful to save from the old configuration is the SSH host key.)

(Log in to post comments)

Host authenticity check

Posted Feb 17, 2007 6:18 UTC (Sat) by k8to (subscriber, #15413) [Link]

To be honest, I get these warnings in all sorts of normal situations, and I'm not sure how it can be reasonably addressed.

Recently I went through a process of evaluating various unix variants on my new AMD64 system. Other systems connecting to it received warning after warning as each install generated a new host key without asking me. Sure I could (theoretically) transfer the key from one system to the next, if they could read each other's filesystems, or whatever. Realistically neh.

Disaster recovery frequently changes the host keys.

Operating system upgrades typically result in host key changes.

Referring to the same computer by different names results in a different but similar warning. Worse, when one of the names is really a service name, and ssh seems to have (perhaps cannot have) any provision for recognizing this, resulting in a series of warnings in different scenarios.

The long and the short of it is that most administrators seem to view the entire class of warnings as crying wolf, and ignore them. You may think these admins are all sloppy, but I claim that the sum of the above issues means this result is basically inevitable in all but the most controlled of conditions. I basically notice the message, think about whether there is a reaonable explanation, and if so I ignore it. If there is not a reasonable explanation then I investigate.

Host authenticity check

Posted Feb 17, 2007 16:15 UTC (Sat) by jreiser (subscriber, #11027) [Link]

Ssh can trigger the unknown host check when connecting to a system that is running from a "live CD-ROM." Such a system generates a new host key upon each boot. The associated mechanisms for keeping persistent state across boots often target the individual user and not the host id.

Host authenticity check

Posted Feb 18, 2007 14:29 UTC (Sun) by juriise (subscriber, #38305) [Link]

>Referring to the same computer by different names results in a different
>but similar warning. Worse, when one of the names is really a service
>name, and ssh seems to have (perhaps cannot have) any provision for
>recognizing this, resulting in a series of warnings in different
>scenarios.

These two servers are acccessed through the same ip using destination nat. With the HostKeyAlias, ssh cheks the host key without beeing confused.

host egg
  hostname www.xxx.net
  User riise
  HostKeyAlias egg-axx
  CheckHostIp no
host morr
  hostname www.xxx.net
  User riise
  port 10022
  HostKeyAlias morr-axx
  CheckHostIp no

Port numbers in known_hosts

Posted Feb 19, 2007 8:46 UTC (Mon) by dtucker (subscriber, #6575) [Link]

Starting in 4.4, OpenSSH will also record the port number against the host key when you use a non-standard port so you don't actually need the hostkeyalias. When this happens you will see entries like this in your known_hosts file:

[1.2.3.4]:222 ssh-rsa AA...

It doesn't happen if you set HostKeyAlias and it transparently falls back to the non-port-specific one if need be, so most folks probably haven't noticed.