Opened 16 months ago

Closed 15 months ago

Last modified 13 months ago

#861 closed System Defect (worksforme)

sshd wont start because of hosts.allow and hosts.denyssh

Reported by: yggdrasil Owned by: kris
Priority: minor Milestone:
Component: System Configuration Version: 9.2-RELEASE
Keywords: sshd ssh_exchange_identification Connection closed remote host Cc: trac-bugs@…


I ran into a problem running sshd on my machine with my 9.2-RELEASE. On earlier versions it was sufficient to add a pf rule, add sshd_enable="YES" to rc.conf.local and just service sshd start.
In my current 9.2 install, I also had to remove the example hosts.allow and hosts.denyssh files in /etc for sshd to not disallow remote connections. Although hosts.denyssh is empty, with it outside connections would fail with a
ssh_exchange_identification: Connection closed by remote host
Without it everything works as expected.

Change History (5)

comment:1 Changed 15 months ago by joshms

  • Owner set to kris

comment:2 Changed 15 months ago by kris

I'm not seeing this happen on my boxes. The only time those files deny you connections is when they have an IP address in them to block. Do you have anything in hosts.denyssh or hosts.deniedssh?

comment:3 Changed 15 months ago by yggdrasil

As I wrote, it's empty. I was very surprised by this too, but what remains is, that sshd won't accept incoming connections as long as an (even empty) hosts.deniedssh exists. Once I removed the file sshd allowed connections again.

comment:4 Changed 15 months ago by kris

  • Resolution set to worksforme
  • Status changed from new to closed

So, I've done some additional testing on this, and cannot duplicate what you describe.

In my /etc/hosts.allow, I have this at the bottom:

# denyhosts
sshd : /etc/hosts.deniedssh : deny
sshd : ALL : allow

The hosts.deniedssh file exists and is empty, and it doesn't cause any problems connecting here that I can see...

If you can post your hosts.allow file and listing of /etc/hosts.* that may be helpful, but at the moment this doesn't appear to be a system-wide problem.

comment:5 Changed 13 months ago by yggdrasil

just installed a fresh 10.0, and I had the exact same problem again. After reading the hosts.allow, it seemed to be the source of the problem, because the _first_ matching rule inside it wins. Uncommenting the very first "ALL : ALL : allow" rule makes it work again. So one of the example rules in between must have been the cause of the problem.

Note: See TracTickets for help on using tickets.