Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm using a combination of /etc/hosts.deny and ufw on my ubuntu 10.04.04 server. Most days, I see failed ssh attempts from machines in the .com.cn domain, reported like so:

Failed logins from:
112.114.63.139 (139.63.114.112.broad.km.yn.dynamic.163data.com.cn): 1 time

However, in /etc/hosts.deny, I have this rule:

ALL: .com.cn

Shouldn't this be blocking the connection before it even hits ssh? I've tested it via blocking my home machine, and it certainly denies me a connection right away before I get a login prompt (and yes, I've moved my ssh keys away so those aren't involved).

Is this working as intended?

Edit: James Sneeringer prompted me to look more closely at the logs, and perhaps I see why this is happening. From auth.log:

Nov  5 09:38:40 mymachine sshd[22864]: warning: /etc/hosts.deny, line 21: can't verify hostname: getaddrinfo(139.63.114.112.broad.km.yn.dynamic.163data.com.cn, AF_INET) failed
Nov  5 09:38:44 mymachine sshd[22864]: reverse mapping checking getaddrinfo for 139.63.114.112.broad.km.yn.dynamic.163data.com.cn [112.114.63.139] failed - POSSIBLE BREAK-IN ATTEMPT!
Nov  5 09:38:45 mymachine sshd[22864]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.114.63.139  user=root
Nov  5 09:38:47 mymachine sshd[22864]: Failed password for root from 112.114.63.139 port 37245 ssh2
Nov  5 09:38:47 mymachine sshd[22866]: Connection closed by 112.114.63.139

This implies to me that if sshd isn't sure about the IP->name lookup, then it errs on the side of caution and does not block that host. Is that right?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

This is expected for sshd because it is linked directly to libwrap, so sshd is actually what performs the host check. If you want to block the connection before sshd is invoked, you'll need to place something in front of it to handle the connection attempt before passing it off to sshd. A couple options would be:

  • Run sshd under inetd (or xinetd). This will allow you to invoke sshd as an argument to tcpd, and tcpd is what ends up performing the actual host check.

  • Run sshd under xinetd, which has only_from and no_access service options that provide functionality similar to /etc/hosts.allow and /etc/hosts.deny.

The sshd manpage discourages these approaches, though:

 -i      Specifies that sshd is being run from inetd(8).  sshd is normally
         not run from inetd because it needs to generate the server key
         before it can respond to the client, and this may take tens of
         seconds.  Clients would have to wait too long if the key was
         regenerated every time.  However, with small key sizes (e.g. 512)
         using sshd from inetd may be feasible.

Using iptables or placing a firewall in front of your server might seem like a good alternative, but most do not perform any name resolution, so you're limited to controlling access by IP address. This isn't necessarily a bad thing, but it doesn't help with what you're trying to accomplish.

share|improve this answer
    
OK, that sounds just fine. The way it was logging the (attempted) user info instead of just the banned domain made it seem like it was just falling through to normal ssh user authentication & rejection, but it's working, I'm happy. Thanks! –  khedron Nov 2 '12 at 15:46
    
Now, the results of my self-banning experiment have showed up in the logs today, and they're in a different category than the .com.cn rejects. They're nicely explicit: "Refused incoming connections:", instead of "Failed logins from" or "Illegal users from". ... are you sure the .com.cn ban is working? –  khedron Nov 2 '12 at 15:49
    
It would help to see the exact (anonymized) log messages you're getting. However, judging from the OpenSSH source code, it looks like it consults tcp_wrappers pretty early in the process, so I wouldn't expect user-specific log messages for connections refused due to /etc/hosts.deny. –  James Sneeringer Nov 5 '12 at 19:23
    
James, any advice you can offer is appreciated! It surprised me as well -- I hadn't checked the code, but had the same thought that user-checking would be mean that the connection process had gone further than I'd expected. –  khedron Nov 6 '12 at 17:29
    
Please post some sample syslog entries. The "Failed logins" message doesn't come from either sshd or libwrap, and looks more like output from logwatch. –  James Sneeringer Nov 6 '12 at 17:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.