Bug#81668: the "fix" that caused this symptom is solving the wrong problem
The canonical system name (as returned by name servers) is used
by sshd(8) to verify the client host when logging in; other names
are needed because ssh does not convert the user-supplied name to
a canonical name before checking the key, because someone with
access to the name servers would then be able to fool host au-
thentication.
If we can't rely on nameserver replies (and we can't) then relying on
checking any name against the one in known_hosts.
Let's look at the (bogous) "exploit":
The exploit would go something like this.. I have accounts on
three boxes A, B and C. I'm currently using A. An attacker has
compromised C, and has the capability of spoofing my DNS.
I ssh from A to B.
SSH asks for B's IP, the attacker replies with the IP of C.
SSH asks for the IP's PTR record, to get the canonical host name.
DNS (rightfully) gives C.
SSH connects to C, checks the host key against the canicalized
name "C", host key matches. I get prompted for a password, and
I type my password on B. Attacker has compromised my account on B.
1. If the attacker has the ability to spoof my DNS, I have been
compromized. It doesn't need to resolve to a FQDN, a spoofed DNS can
resolve my "shortname" to the IP of their choice. They can do this for
all my services, not only ssh.
2. To mediate this disaster, ssh should check hostkeys based purely on
IPs. If the *IP*'s don't match, the hostkeys don't get checked at all,
and you'll get an "I've never heard about this host before" ssh
dialogue:
The authenticity of host 'foo (192.168.1.42)' can't be established.
RSA key fingerprint is 10:2f:27:49:66:48:31:de:69:55:a5:79:9d:fa:cc:ce.
Are you sure you want to continue connecting (yes/no)?
Sounds better, doesn't it?
Now my .ssh/known_hosts file should still have my _unencrypted_ short
name (the one I asked for the 1st time I used ssh against that host)
tied to the host key I got that first time, along with the
_fingerprint_, as that's the only thing readably checkable and
verifiable by a simple mortal.
BUT considering the amount of unresolved and wontfix bugs at
http://bugs.debian.org/ssh
and the, eh, quality of the very first bug I end up reading while
about to post my own,
this might not be the most effective forum for improving the quality
of ssh. With this many unclosed bugs (some with patches available!)
looks like there's noone reading them, nor even forwarding upstream.
If you are neither an SSH developer nor a Debian maintainer, nor plan
to be either, why are you butting in Tommi? What's it to you? It's not
like you're helping, is it?
Reply to: