# "reverse mapping checking" by sshd failed..

## Monkeywrench

I see the following messages in my sshd logs whenever I log in from my school computer lab:

```
Nov  8 09:10:19 [sshd] Accepted publickey for nile from 150.176.245.171 port 2561 ssh2

Nov  8 09:10:20 [sshd] reverse mapping checking getaddrinfo for 245-171.sfcc.edu failed - POSSIBLE BREAKIN ATTEMPT!
```

I have putty.exe on a USB keydrive, along with my private key. I use the private key with putty to log into my home server, and I get these messages. I don't know if it's limited to my lab, because I don't think I've ever sshed in from any other place. However, when my friend logs in with ssh, there are no errors.

Another (maybe related) issue: whenever I try to use ssh tunneling between the computer lab and my sshd server at home, nothing happens. I know the connection is established, because putty says "port forwarding opened for ..." and I do know how to use port forwarding, since it works on my local network.

No time now, but I'll post more details later if asked for..

----------

## smutt

SSHD is trying to do a reverse DNS lookup for the domain "245-171.sfcc.edu".  But since there is no PTR record in DNS for that host the lookup fails.  You'll typically get this whenever you try to ssh through a FW.  It's nothing to worry about.

Check out this entry from sshd manpage if you want to make this stop:

```

     -u len  This option is used to specify the size of the field in the utmp structure that holds the

             remote host name.  If the resolved host name is longer than len, the dotted decimal value

             will be used instead.  This allows hosts with very long host names that overflow this field

             to still be uniquely identified.  Specifying -u0 indicates that only dotted decimal

             addresses should be put into the utmp file.  -u0 may also be used to prevent sshd from mak-

             ing DNS requests unless the authentication mechanism or configuration requires it.  Authen-

             tication mechanisms that may require DNS include RhostsRSAAuthentication,

             HostbasedAuthentication and using a from="pattern-list" option in a key file.  Configuration

             options that require DNS include using a USER@HOST pattern in AllowUsers or DenyUsers.

```

----------

## SoTired

Well the error message means the host name for the IP address does not map to the resolved IP address of that hostname - so you must be going through a proxy of some sort.

You could set 

```
VerifyReverseMapping no
```

 in your /etc/ssh/sshd_config file, to prevent it from doing that check.

Turning it off might get tunneling to work, though I wouldn't hold my breath if I were you.  Any chance you could do some packet dumps or something to see where the protocol breaks down when you try forwarding?

Out of general interest, what version of ssh are you using?  The VerifyReverseMapping directive isn't referenced in the up to date documentation so updating (if possible) might help as well.

----------

## smutt

SoTired,

  You're right.  SSHD first gets an IP and looks up a hostname[245-171.sfcc.edu] via PTR record.  

Then SSHD looks for an A record for the hostname[245-171.sfcc.edu].  

This is what is failing.

But this doesn't necessarily mean he is going through a proxy.  I have the same thing when I connect from work.  I just ignore the message as it doesn't matter to me.  The reason SSHD cares is because it relies on DNS to determine which key to look for.  If you're not using HostbasedAuthentication then it doesn't really matter.  Just enter a password every time you log in.

--Smutt

----------

## Monkeywrench

Hm, any idea how to fix the forwarding issue, though? I'll attempt to get a packet dump of what's going on the next time I have access to the lab. Also, what's PTR mean?

Thanks for the help, everyone  :Smile: 

----------

## smutt

A PTR record in DNS is the opposite of an A record.  An A record maps a name to an IP address.  While a PTR record maps an IP address to a name.

And now on to the SSH forwarding:

Are you sure you can get to your home machine from your work machine on the TCP port that SSH is running on? 

If you telnet to the port on the home machine that you are connecting to from work do you see something?  You should atleast be able to establish a TCP connection even if it is gibberish.  

Do you see any logs on your home PC when you are attempting to setup port forwarding?

--Smutt

----------

## Monkeywrench

 *smutt wrote:*   

> Are you sure you can get to your home machine from your work machine on the TCP port that SSH is running on? 
> 
> If you telnet to the port on the home machine that you are connecting to from work do you see something?  You should atleast be able to establish a TCP connection even if it is gibberish.  
> 
> Do you see any logs on your home PC when you are attempting to setup port forwarding?
> ...

 

Yes, I'm sure. I can use putty to connect fine. When I set port forwarding options, it still connects fine (putty even displays the correct "port forwarding established" messages in its event log). It's just when I actually go to use the ports that I run into trouble. If it helps any, what I'm trying to use the tunnel for is an encrypted VNC connection. When I try to use the VNC viewer to connect to the localhost, it just hangs. This is weird, though, because if I just enter a random address, the viewer tells me that it can't connect.

And no, I don't see any peculiar log messages, besides the ones I already pasted above.

Thanks!  :Smile: 

----------

## smutt

Sounds like the remote VNC server can't send traffic back to your VNC client.  My guess is that your client is timing out waiting for a response from the VNC server.

You might want to check this out.

http://pigtail.net/LRP/vnc/

--Smutt

----------

## jmarcus

I set sshd to startup like this 

```
/usr/sbin/sshd -4 -u0
```

----------

