There is an important difference between host-based authentication in protocols 1 and 2: in SSH-2, the authentication request contains the client hostname, whereas in SSH-1 it does not.

Now, the server needs some sort of client host identifier to perform authentication. Specifically, for two operations:

• looking up the client host key, and
• performing authorization via hosts.equiv/shosts.equiv/.[rs]hosts

• mobile client with changing IP address and corresponding name
• client behind a network-visible proxy, e.g. SOCKS
• multi-homed client, unless the DNS entries are arranged in a particular way

As currently implemented, though, SSH2 does not do this. sshd2 uses C_N for HAUTH, and only uses C_A as a sanity check: if C_N != C_A, it fails the authentication. This is really backwards, and causes hostbased authentication to be much less useful than it could be, since it continues to not work in the scenarios noted above. Instead, it should use C_A for HAUTH, and implement the C_A = C_N check as a per-host option. That makes sense as an extra bit of security, in cases where it's known that the client host address should never change. This is analogous to public-key user authentication, which is independent of the client address, but which admits optional address-based restrictions via the hosts authorized_keys option.

Because of the way SSH implementations have developed, the authentication and authorization functions are hopelessly entangled, making the software much less flexible than it could be. The most glaring example of this are the restrictions available in the authorized_keys file. Using options such as host=... and command=..., you can restrict the source hosts allowed to connect using a particular key, or force a certain program to be run instead of allowing the client to specify one. But because they're implemented in the authorized_keys file, these authorization features are availble only when using public-key authentication -- even though they make perfect sense to use as retrictions to the account, regardless of what method was used to authenticate the client!

The result is that you may be forced to use public-key authentication, even when another method would be more appropriate, just in order to get sufficient control. Perhaps you'd like to use trusted-host authentication for a batch job, or Kerberos because your computing environment supports it -- but the weak authorization controls available for them force you to use public-key anyway. Or perhaps you'd like to bar access to your account via password authentication -- but you can't do that without turning off password authentication for the server as a whole, even though you can prevent access by public-key simply by having no authorized_keys file.