Even if it used gethostbyname() , I fail to understand how one would supply an invalid IP address to an sshd program? It calls an IP resolver after the TCP connection has been established, reading off the IP from there. From what I understood from their exim HELO example, one has to feed in a crazy IP "address" to gethostbyname() to trigger the bug.

Well, it obviously does getaddrinfo() on the incoming TCP connection to get the hostname (which is reported in the log, unless you have a 'UseDNS no' directive) -- and at least in my setup (which is mostly vanilla Debian), it seems to resolve that name again to an IP address, compare that to the IP address of the connection, and warn if it does not match.

Thus, an attacker controlling the PTR record for a given IP might provide a GHOST-compliant name in that PTR record; Then, connect to the ssh daemon, wait for it to read the PTR record - and if it gethostbyname() on it, it's game over.

Quite a few log processors would do that. The reason I'm worried specifically about sshd is that it is usually the only port ever listening to the world-and-not-firewalled on my servers (and a non-standard, at that - and only allowing public key authentication) - but despite this generally-regarded-as-secure setting, GHOST may prove it vulnerable.

But why would this malicious PTR record be fed into gethostbyname() again? At that point of getting a reverse lookup result, sshd is done checking.

To see that it resolves back to the IP address from which the connection is made. It's a standard check that many servers do, and ssh does too (and gives off a warning if they don't match). I'm not sure if it does it in a way that's vulnerable or not, though - but it surely does so by default.

From man sshd_config:

     UseDNS  Specifies whether sshd(8) should look up the
     remote host name and check that the resolved host name
     for the remote IP address maps back to the very same 
     IP address.  The default is “yes”.