When you connect to a host using SSH or SFTP it does a series of checks to ensure you are connecting to the host you are expecting to connect to. One of these is a reverse lookup on the IP address to check the hostname is the same as the hostname you are connecting to. If it's not, you'll get an error message like "reverse mapping checking getaddrinfo for ... POSSIBLE BREAK-IN ATTEMPT!". The post looks at a solution to this message.
Reverse DNS not set up
Connecting from the command line, you might enter something like this:
1
ssh my.example.com
and get some output like this:
1
Connecting to my.example.com...
2
reverse mapping checking getaddrinfo for 192-168-1-243.foo.bar.net failed - POSSIBLE BREAK-IN ATTEMPT!
3
chris@my.example.com's password:
What this is telling us is that although we are connecting to my.example.com the IP address of the server we are connecting to actually maps back to 192-168-1-243.foo.bar.net in this example. When this actually happened to me, it's because the reverse DNS had not been set up for the server (which would map e.g. 192.168.1.243 to my.example.com as well as vice versa).
Hosts file solution
Because I knew this reverse mapping was OK, I can add an entry to my hosts file and it will stop the error message from happening. For the above example, I would add the following to my hosts file:
1
192.168.1.243 my.example.com
Now when I log in using SSH from the command line I won't get that error message any more.
PTR record for IP doesn't resolve to valid host
The following update is thanks to Sean Straw and was added to this post August 23rd 2010.
This error also occurs when the PTR record for the IP of the client system doesn't resolve to a valid host.
From an as-I-write-this current bogus host (log entry from one of my servers, but connecting system is not my IP space or domain - deru.net is an Arizona ISP, and I'm neither geographically near them nor associated with the outfit):
1
reverse mapping checking getaddrinfo for 179.cureconsulting.deru.net [140.99.28.179] failed - POSSIBLE BREAK-IN ATTEMPT!
01
$ host -a 179.28.99.140.in-addr.arpa
02
Trying "179.28.99.140.in-addr.arpa"
03
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28045
04
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
05
06
;; QUESTION SECTION:
07
;179.28.99.140.in-addr.arpa. IN ANY
08
;; ANSWER SECTION:
09
179.28.99.140.in-addr.arpa. 85913 IN PTR 179.cureconsulting.deru.net.
10
11
;; AUTHORITY SECTION:
12
28.99.140.in-addr.arpa. 85913 IN NS ns2.deru.net.
13
28.99.140.in-addr.arpa. 85913 IN NS ns1.deru.net.
14
15
Received 121 bytes from **REDACTED**#53 in 4 ms
This tells us what we already knew from the log entry - the reverse dns (PTR record) for the connecting IP resolves to that 179... hostname.
1
$ host -a 179.cureconsulting.deru.net.
2
Trying "179.cureconsulting.deru.net"
3
Received 96 bytes from **REDACTED**#53 in 2 ms
4
Trying "179.cureconsulting.deru.net"
5
Host 179.cureconsulting.deru.net. not found: 3(NXDOMAIN)
6
Received 96 bytes from **REDACTED**#53in 3 ms
This tells us that the host doesn't actually resolve.
Reasons for PTR record issues
This could be malicious, or it could be incidental to poor IT practices. Sadly, it isn't uncommon for some small (and large) hosting outfits to not clean out ALL records associated with customers which they drop. So, let's say they don't delegate PTRs, and drop a customer without clearing the PTRs associated with that customer (they may have dropped the zone for the client domain though). Now, the next poor SOB that gets assigned that address doesn't necessarily know to ask to have the PTR updated to reflect their domain.
Another scenario is that one of the many people attempting to crack into systems has set a bogus PTR for their origin so as to misdirect simple inquiries. If the netblock is delegated to them and the PTRs as well, this doesn't really conceal much, since whois on the netblock will point the way. However, if they've got an ISP host that provides a web form for them to change DNS for the handful of IPs that might be assigned in a static block, they could use that to provide bogus hosts. I've always seen these messages in conjunction with brute force intrusion attempts.
