From Current (pre-release) ChangeLog for x86_64
If I want to check the TCP Wrappers support for SSHD with the command:
there is no result returned!
If I run
result is
They are already installed:
openssh-7.7p1-x86_64-2
tcp_wrappers-7.6-x86_64-1
but libwrap.so.0 is missing.

There was no shared libwrap before, either.

I have build OpenSSH from sources (openssh.SlackBuild) and I found:
and

Yes, I found it here:
https://www.linuxquestions.org/quest...kernel-554912/
but there's a patch for "shared libwrap"
https://www.linuxquestions.org/quest...ce-4175608633/

<digression>
Can I ask what use-case(s) you have for TCPwrappers (tcpd) that is not already met by iptables?
</digression>

TCP Wrappers provide an additional layer of security after firewall and before service daemon.
Is a good approach, because even if firewall is breached, the attacker still has to overcome the extra wrapper.
I'm using an iptables-based firewall (it will be replaced by nftables) but I've been using TCP Wrappers since I started using Linux for servers.
Example: I use TCP Wrappers to restrict SSH server access by workstations in the internal network.

Thanks, can you explain in a little more detail about which tcpd-specific features you are using or plan to use? Restricting by IP number or subnet can be done with iptables (or nftables) alone so in that regard tcpd is redundant and provides no added help.

I use TCP Wrappers mainly to restrict SSH access. External IP addresses that can access the SSH server are filtered by firewall (iptables) and TCP Wrappers but internal IP addresses only by TCP Wrappers.
It is your point of view that tcpd is redundant, for me it adds an extra level of protection.

You could also use DenyUsers, AllowUsers, and Match conditional blocks in sshd_config.

No. It is not a point of view. It is a fact that tcpd, for that use-case, is redundant. There is no need to use it for filtering since iptables does that without adding extra code or requiring modifications to the OpenSSH package. If you do not believe me, then look at iptables and see that you can filter by IP address and subnet, including LAN addresses. iptables can even filter by date, day of the month, day of week, or hour of day. Also, the NFQUEUE target can trigger user-space activvity. See "man iptables" and "man iptables-extensions"

See also the manual page for sshd_config itself and check the configuration directives AllowUsers, AllowGroups, DenyUsers, DenyGroups, or Match's Address. Notice that they provide filtering by IP address and even by subnet using CIDR notation in addition to some basic wildcard substitutions.

By being redundant, an argument can be made that tcpd actually lowers the protection you have available by introducing undesired complexity and large amounts of legacy code. If it's not there, it can't break.

Keep it simple.

Again, I used to use tcpd and so have been honestly curious about other use-cases that are above and beyond filtering, ones that would really be something extra. So I was really hoping to read something interesting like using it to trigger shell scripts from hosts.allow or hosts.deny upon receiving requests for incoming connections. Back when a finger daemon was part of every server, it used to be reasonable sometimes to probe the incoming machine for that user's account. I suppose nowadays you could use tcpd for a quick nmap scan of the remote machine or something similar. That's the kind of use-case I was hoping to read about.

Anyway thanks for explaining, even if I disagree, and sorry for the digression.

I'm already using the AllowUsers directive but I have not yet used Match's Address.
It was easier to configure the permissions in the hosts.allow file.
I read that TCP Wrappers is deprecated in many distributions but there are other solutions.
Thanks for your explanations, they helped me better understand this situation.

This reasoning is why I rebuilt the OpenSSH package after Pat decided to add tcp_wrapper back in. I'm not suggesting there's anything wrong with the patch he's using, but as the infamous debian openssl debacle taught us: when you start messing with other peoples code bad things can happen. OpenSSH is a high risk component, so I prefer it to be as true to upstream as possible. If they dropped support for tcp_wrappers then I'm not going to second guess them and add it back in.

2 members found this post helpful.

Yeah - I have been in two minds about that one as well. iptables maybe a single point of failure, but it is also a single point of maintenance. On balance, I prefer to go with iptables only.

1 members found this post helpful.

At this point, tcp_wrappers is so well audited that I'd be very surprised if a security problem exists there.

You almost changed my mind, though. Next time the patch breaks I'll be much harder to convince.

1 members found this post helpful.

I have the luxury of only having to consider my own preferences, which makes the decision much easier.