Re-install libwrap in OpenSSH

Malcolm opensshdev at
Thu May 21 18:35:10 AEST 2015

Quoting Stephan von Krawczynski <skraw at>:

> Let alone all the useless suggestions involving
> firewall->systemd->fail2ban schemes which do not help at all against stolen
> passwords or keys. Risk does increase with complexity of security measures
> so firewall per se is no real comparable option. Reasonable firewall rules
> tend to look like spaghetti code implementing a bigger number of
> to-be-whitelisted ips.

Why would they end up that way?

Most organisations place firewalls at their network border or edge, and
implement service access policies in a consistent and transparent manner as
far as the servicing hosts themselves are concerned.  Log coalescing allows
"bruteforce" attacks to be collected and if necessary acted upon also in a
centralised and consistent manner.

The "economy" of which you speak regarding libwrap functionality sounds like
each host you run operates like an island unto itself, rather than as a
coordinated team of servers managed by consistent policy.

> In the end, every replacement for libwrap is just a risky and bad patch for
> the real thing. So why throw away code that works since decades, is simple,
> has simple usage pattern? 

The OpenSSH team has no doubt looked at the "risk profile" of linking to
various bits of code, and libwrap is by no means the only one to see a
potential axe here.  

Notice too that OpenSSL's track record has gotten to the point where the
OpenSSH team has looked to allow system administrators to build sshd/ssh
WITHOUT linking against any OpenSSL code at all.  Given how much cruft and
"legacy" support that's been exploited for years by hackers and three-lettered
US agencies alike, I think that's a sensible posture, to be honest.

I just realised that I spent a non-trivial amount of time DISABLING
MACs/KEXs/Ciphers across my entire organisation to the point where simply
building without any OpenSSL would have probably saved much more time to start
with!  At some point, I think I'll make a "split patch" where the clients
(ssh/scp) can get built one way and the server components another. 

Sure, I can simply build it twice and manually merge them today, but I'm a
software engineer, not a system administrator, and I'm *LAZY*.

Your approach is both counterproductive, and unnecessary.  If you actually
looked through the archives, you'll find patches to re-incorporate support for
libwrap without any difficulty whatsoever into OpenSSH.

It sounds like you are wanting to have it both ways - you mention a loathing
for "fail2ban" and similar strategies - which are entirely automated surgical
firewalling rules put into place to reduce bruteforce attack pressure on
hosts, versus the "labour cost differential" of hand-edited host.allow/deny

Are you saying that you prefer to manually enter and retire "attacking hosts'
IP#s" that have too many password failures against your servers?


More information about the openssh-unix-dev mailing list