/etc/ssh/sshd_config: line 150: Bad configuration option: hosts.allow

P

patrickkasie

Verified User
Joined
Sep 21, 2021
Messages
244
Location
Een echte Hollander
Dear DirectAdmin forum,

I have set up my servers to have the following lines in /etc/hosts.allow:

Code: 
sshd : localhost : allow
sshd : 192.168.1. : allow
sshd : my.own.ip.address : allow
sshd : ALL : deny

However, some of the servers do not seem to take the /etc/hosts.allow into account, where I'm capable of connecting to those servers on a foreign IP address. I have taken in the answer from ChatGPT to do the following:

Check SSH Configuration: First, confirm that your SSH server is configured to use /etc/hosts.allow and /etc/hosts.deny. The SSH server configuration file (sshd_config) should have the following settings:

shellCopy code
/etc/ssh/sshd_config:

# /etc/hosts.allow and /etc/hosts.deny
hosts.allow
hosts.deny
Click to expand...

Resulting in the following error:

Code: 
-- Unit sshd.service has begun starting up.
Oct 09 09:53:56 dabackup.domain.nl sshd[1930]: /etc/ssh/sshd_config: line 150: Bad configuration option: /etc/hosts.allow
Oct 09 09:53:56 dabackup.domain.nl sshd[1930]: /etc/ssh/sshd_config: line 151: Bad configuration option: /etc/hosts.deny
Oct 09 09:53:56 dabackup.domain.nl sshd[1930]: /etc/ssh/sshd_config: terminating, 2 bad configuration options
Oct 09 09:53:56 dabackup.domain.nl systemd[1]: sshd.service: Main process exited, code=exited, status=255/n/a
Oct 09 09:53:56 dabackup.domain.nl systemd[1]: sshd.service: Failed with result 'exit-code'.
-- Subject: Unit failed

I had already noticed that the /etc/hosts.allow files on those servers did not exist from the moment I created them, but on other servers where the files do exist, they also include some comments detailing how the file works. It seems to be on those servers that there's no failed login attempts on SSH because the IP addresses get properly blocked, which is what I'm aiming for. How do I get to have this result on all servers? The following OS's are affected:
CentOS 7
CentOS 8
AlmaLinux 8.8

Edit: Some servers do not have CSF, nor would I like to add that to said servers. I would like to streamline everything in the same way with /etc/hosts.allow
 
I didn't test it on RHEL, but in Ubuntu I use 2 files hosts.allow and hosts.deny:
09-10-2023 11-46-33.jpg
09-10-2023 11-46-47.jpg
 
Alright, but how is this relevant to the issue at hand? I have 1 of the files present and the error message tells me about 2 files being incorrect, 1 of which I do have
 
so make it like in my working example, maybe it don't like sshd : ALL : deny line in allow-file and want it it deny file etc.
 
I've just edited both files into the format you gave me and removed my lines from the /etc/ssh/sshd_config. No change, still new failed attempts coming in. Besides, you have detailed explanations in your files, which implicates that your server understands it has to use those files
 
As I googled - it differs in RHEL8

Securing SSH using Firewalld on RHEL8 or CentOS8 Replacing TCP_Wrappers | Free Linux Tutorials

As per Redhat official document titled ""Replacing TCP Wrappers in RHEL 8" (https://access.redhat.com/solutions/3906701 ), it says: The TCP Wrappers package has been deprecated in RHEL 7 and therefore it will not be available in RHEL 8 or later RHEL releases. You won't be able to see this...
freelinuxtutorials.com freelinuxtutorials.com
better one I think: https://zedt.eu/tech/linux/how-to-filter-ssh-connections-with-hosts-allow-on-rocky-linux-8/
 
I've used the second link and it works flawlessly. I already came across the first one myself, but figured it wasn't for me. Thank you for taking your time to help investigate this issue.
 
I'm afraid I have to re-open the topic. It works for AlmaLinux 8, but not for CentOS 8 as I get the following error:
Code: 
CentOS Linux 8 - AppStream                                                                                                                                                       24 kB/s | 7.9 kB     00:00
Errors during downloading metadata for repository 'appstream':
  - Status code: 404 for http://mirror.centos.org/centos/8/AppStream/x86_64/os/repodata/repomd.xml (IP: 2001:4178:5:200::11)
Error: Failed to download metadata for repo 'appstream': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
I do not know how to use IPTables to perform this action though. I just know what it is and how to add and remove an IP address from connecting with the server, but not how to make it so SSH logins can only happen from my IP addresses like /etc/hosts.allow would allow for
 
patrickkasie said:
for CentOS 8 as I get the following error:
Click to expand...
This is logical because Centos 8 is EOL and not supported anymore. So yum installation commands will not work anymore for this.
Best is to convert Centos 8 to Almalinux 8.

As for CSF, you can use the csf.allow file to limit access easily on ip or domain base:
tcp|in|d=22|s=192.168.0.1
or
tcp|in|d=22|s=host.domain.com

Ofcourse change ip or hostname and the SSH port to your needs.
Don't forget to restart csf/lfd afterwards.

P.s. you might need to remove port 22 (SSH port) from the allowed ports in that case, otherwise it will still be open.
 
That should have been my go-to option. It's a backup server which shouldn't have access to the outside world, and now it doesn't, so I think we're good if that server stays around for another 10 to 20 years in its current state... well, as long as Unix time supports the current OS, realistically speaking, January 19th 2038. Edit: this works, thank you
 
Again, have to re-open this.

I've noticed today again that there were a lot of failed login attempts after rebooting the server yesterday afternoon. This applies to the AlmaLinux servers only, not CentOS8.

When I connected to said servers, they had a lot of failed attempts again. This is strange, because they were completely gone just last night when I checked over the timespan of a couple of hours. Upon checking the status of the services, all AlmaLinux servers showed the same thing, even though I've gone through the steps as provided by the 2nd link by Zhenyapan

Code: 
  986  systemctl stop sshd.socket ; systemctl start sshd
  987  systemctl disable sshd.socket ; systemctl enable sshd
(This was a mistake yesterday, I correct this later)
  988  systemctl status sshd.socket ; systemctl status sshd
(dead ; alive)
  989  systemctl stop sshd ; systemctl start sshd.socket
(works ; works)
  990  systemctl status sshd.socket ; systemctl status sshd
(alive ; dead)
  991  clear
  992  systemctl status sshd.socket
(alive)
  993  reboot
  994  history
  995  systemctl status sshd.socket
(dead)
  996  systemctl disable sshd ; systemctl enable sshd.socket
(removes symlink -if I recall correctly- ; creates symlink -this I do remember-)
  997  systemctl stop sshd ; systemctl start sshd.socket
(works ; works)
  998  systemctl status sshd.socket
(alive)
  999  reboot
 1000  systemctl status sshd.socket
(dead again)
 1001  systemctl status sshd
(alive)
 1002  systemctl disable sshd ; systemctl enable sshd.socket
(nothing happens)
 1003  systemctl status sshd.socket
(dead)
 1004  systemctl status sshd
(alive)

Why do the servers not want to roll over from sshd.service to sshd.socket?
 
Last edited:
Just asking the obvious maybe, but why should login attempts disappear? I'm curious about that, since bruteforcers always will keep trying to login and so generating failed login attempts. Unless you managed to totally close port 22.

The socket way maybe is too difficult.
I would just remove port 22 incoming and outgoing from csf and then use the csf.allow to add the ip's which should be able to login.
Then port 22 will be closed, end of story. Can't be much easier, right?
 
Richard G said:
Just asking the obvious maybe, but why should login attempts disappear? I'm curious about that, since bruteforcers always will keep trying to login and so generating failed login attempts. Unless you managed to totally close port 22.
Click to expand...
Because as per Zen's second link, killing off sshd.service and giving life to sshd.socket, all failed logins to SSH are non-existent anymore. When I try to connect to any of the servers at all, I just immediately get a Connection refused, which is what I feel is better in general, though my feeling might just be incorrect here, though I think it makes sense that foreign IP addresses shouldn't even get the opportunity to as much as connect to my servers. So, the issue arises when I want to use the command to prevent sshd.service from starting with Linux, while trying to enable sshd.socket.

Much weirder even, at a random time just last night when no one was at the office, both services flipped status again. sshd.service is alive again and sshd.socket is dead again. On all AlmaLinux servers.

Richard G said:
The socket way maybe is too difficult.
I would just remove port 22 incoming and outgoing from csf and then use the csf.allow to add the ip's which should be able to login.
Then port 22 will be closed, end of story. Can't be much easier, right?
Click to expand...
I've already set up the socket way, but I should definitely add your method into the mix as well. So I've tried your way, rebooted the server, and from this point forward, the former question more becomes a curiosity about why AlmaLinux specifically doesn't want sshd.socket not to start, and even worse, seems to lead a life of its own. Maybe this is also applicable for other OS'es, but that's the only OS it applies to in my situation. But yeah, your way works. I've closed off port 22 and added my IP address to the csf.allow without any advanced filtering.
 
patrickkasie said:
I just immediately get a Connection refused, which is what I feel is better in general,
Click to expand...
You get the same notice if you try to connect to the wrong port, or a closed port. I don't have port 22 by default anyway.
I don't know if the DA monitoring service might be throwing issues with the socket use.
You might want to try to disable the monitoring service of DA for SSHD and see if that makes any changes for your socket solution.

I don't use any customisation to socket, just change port 22 to something else, have my own ip in the csf.allow and use authorized_keys file. End of problem.
I can also leave port 22 open this way, but nothing is running on it. If I close it a connection refused is issued.
 
You must log in or register to reply here.
Back
Top