Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 531156 - net-misc/openssh-6.7_p1-r1 does not support tcp-wrappers anymore
Summary: net-misc/openssh-6.7_p1-r1 does not support tcp-wrappers anymore
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL: http://lwn.net/Articles/615173/
Whiteboard:
Keywords: PATCH
: 536076 555316 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-11-29 17:26 UTC by Łukasz Stelmach
Modified: 2015-09-07 06:39 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Restore TCP Wrapper support (openssh-6.7p1-libwrap.diff,4.25 KB, patch)
2014-12-11 05:40 UTC, mancha
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Łukasz Stelmach 2014-11-29 17:26:18 UTC
There is no warning message neither in the news nor after upgrading the package (it should be in the news because it may be overlooked after a large world update), that OpenSSH does not support tcp-wrappers. There should be one because some users may be left unprotected.

Reproducible: Always
Comment 1 Kristian Fiskerstrand (RETIRED) gentoo-dev 2014-11-29 18:49:04 UTC
Reassigning this bug to package maintainers. This is not a security vulnerability that will be tracked by the Security team.
Comment 2 Kristian Fiskerstrand (RETIRED) gentoo-dev 2014-11-29 18:49:50 UTC
Sorry about bug-spam, forgot to uncheck "reset assignee to default"..
Comment 3 Thomas Beutin 2014-11-30 16:53:02 UTC
I don't know the status of this manual, but it should be updated:
https://dev.gentoo.org/~swift/docs/security_benchmarks/openssh.html#item-xccdf_org.gentoo.dev.swift_group_config-acl-hosts
Comment 4 Łukasz Stelmach 2014-12-07 10:26:42 UTC
Ping? I don't want to be rude but this is rather important issue.
Comment 5 Thomas Beutin 2014-12-07 11:27:53 UTC
(In reply to Łukasz Stelmach from comment #4)
> Ping? I don't want to be rude but this is rather important issue.

there might be different opinions about importance in this case. And i don't understand why the new release is pushed into portage even if X509 USE flag is not supported. AFAIK there is no security concern about openssh v6.6.x.

Don't get me wrong: i really like tcpd wrappers, and i agree that there __has__ to be a security annoncement from portage, especially if this feature was mentioned in the gentoo documentation.

btw: it seems that this "feature dropping" is a long time before announced by upstream:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html
Comment 6 Łukasz Stelmach 2014-12-07 20:39:57 UTC
Yes, it was announced. However, I came across it quite recently and only by accident. That is why I can imagine people who hasn't. They do their usual "emerge world" and are left with a wide open ssh and without any notice from the package maintainer.

That is why I complain here with all due respect.
Comment 7 mancha 2014-12-11 05:40:27 UTC
Created attachment 391414 [details, diff]
Restore TCP Wrapper support

Hello.

The day OpenSSH 6.7 released I posted a patch that restores TCP Wrapper support (see: http://marc.info/?l=openssh-unix-dev&m=141265241623747&w=3).

Slackware ships OpenSSH 6.7 with my patch and I believe Debian and Ubuntu do also.

You're welcome to it.

--mancha

PS Don't forget to autoreconf -fiv as the patch changes configure.ac
Comment 8 Martin Mokrejš 2014-12-24 16:15:41 UTC
I also pledge for keeping tcp-wrappers support.

1. sshd_config manpage does not explain how to get same functionality.
2. it seems to me I cannot reject connect that early as with tcp-wrappers. Seems this will reject user eventually after he logs in. What a crap.


Match Address 103.41.124.37,61.174.50.229
        PasswordAuthentication no
        ForceCommand /bin/false

For negation people discovered that an asterisk has to be in front, and there is a messy info about delimiter (comma, space sometimes works ...), e.g.:

Match Address *,!127.0.0.1
        ForceCommand /bin/false


3. sshd_config is messy once you want more Match rules.
4. Gentoo docs for ssh are not showing how to use the Match rules at all.
5. other apps use /etc/hosts.{allow,deny} files so no reason to take out sshd. It is simple to edit, maintain, and with app-admin/denyhosts does a great job

Yes, I also see Debian restored tcpd with a patch.

I will now go and ask for stabilization of net-misc/openssh-6.6.1_p1-r4, the last one in the tree which still has the support. I masked >=6.7 myself.
Comment 9 SpanKY gentoo-dev 2014-12-31 07:32:17 UTC
sorry, but we don't have the resources (or desire?) to hand maintain tcpd support in openssh.  it's unfortunate that you relied on it and upstream just dropped it, but that's what they've done :/.

Commit message: Note the removal of USE=tcpd support due to upstream
http://sources.gentoo.org/net-misc/openssh/openssh-6.7_p1-r3.ebuild?r1=1.1&r2=1.2
http://sources.gentoo.org/net-misc/openssh/openssh-6.7_p1.ebuild?r1=1.11&r2=1.12
Comment 10 Thomas Beutin 2015-01-08 13:21:12 UTC
To all the people who like tcpd support:

One can run sshd from (x)inetd which itself obeys to tcpd configuration (/etc/hosts.allow, .deny). The startup delay is almost not noticeable (at least on a recent server).

On xinted there are even more limiting options available, and they are by far easier to understand (by myself) compared to the new introduced access limitation syntax in sshd_config. But of course one cannot limit access by user name/id (because this is only known to the sshd after starting).
Comment 11 Tim Harder gentoo-dev 2015-01-09 05:59:39 UTC
*** Bug 536076 has been marked as a duplicate of this bug. ***
Comment 12 Mark Curry 2015-02-13 23:22:17 UTC
I know this bug has been closed WONTFIX, but I'm going to add a comment here asking the maintainers to please reconsider.

I stumbled on this bug through the forums.

What happened to me was exact what  Łukasz Stelmach feared my happen in Comment 6 below:
  I had a locked down system via hosts.deny (ALL:ALL), and hosts.allow (only 5 whitelisted SSHD connections).  

Did a world update.  Saw NOTHING regarding tcp_wrappers no longer working.

Went about my business for a few days.  For whatever reason, decided to check my logs (I don't regularly do this), and saw all the intrusion attempts on sshd...  I don't lock down everything else as secure, as hosts.deny is a VERY effective first defense.  So I was quite reasonably disturbed...

I know we're slave to upstream decision here, but I'm wondering if there can be more warning for other users in situations like mine.  I'd have prefered emerge flat-out blocked the openssh upgrade if a non-zero hosts.deny was found. 

At the very least some sort of message at the end of emerge (I do read those).

This is a huge security hole.  I don't understand why upstream removed the feature, but I believe gentoo at least owes its users a warning.

Thanks,

Mark
Comment 13 SpanKY gentoo-dev 2015-02-15 08:31:16 UTC
(In reply to Mark Curry from comment #12)

Gentoo has already added a warning to the ebuild as documented in comment 9

adding a pkg_pretend check to poke around hosts.deny should be easy.  is it as simple as grepping for "^sshd" ?
Comment 14 Martin Mokrejš 2015-02-16 17:25:42 UTC
(In reply to SpanKY from comment #13)
> (In reply to Mark Curry from comment #12)
> 
> Gentoo has already added a warning to the ebuild as documented in comment 9
> 
> adding a pkg_pretend check to poke around hosts.deny should be easy.  is it
> as simple as grepping for "^sshd" ?

Actually /etc/hosts.allow can contain same type info but notably, the last "column" will contain word "deny". That makes it equivalent to /etc/hosts.deny file but it is processed much sooner and can reject users right away (which could otherwise match on another condition).

You can grep for protocol name specified in /etc/protocols, so ... duh, why is port 22 associated in the file with 'xns-idp', I don't know. :(( But in theory yes, grep for 'sshd' should have worked.
Comment 15 SpanKY gentoo-dev 2015-03-18 20:23:18 UTC
(In reply to Martin Mokrejš from comment #14)

i've added a check to 6.8p1 ... lets see who complains ;)
  if grep -qs '^ *sshd *:' "${EROOT}"/etc/hosts.deny ; then
    ...die...
  fi
Comment 16 Martin Mokrejš 2015-03-18 20:35:44 UTC
(In reply to SpanKY from comment #15)
> (In reply to Martin Mokrejš from comment #14)
> 
> i've added a check to 6.8p1 ... lets see who complains ;)
>   if grep -qs '^ *sshd *:' "${EROOT}"/etc/hosts.deny ; then
>     ...die...
>   fi

That does not help users having the rule in hostst.allow file. Also, typically there is no space after sshd before the colon, e.g.:

sshd:192.168.0.0/24:deny
Comment 17 SpanKY gentoo-dev 2015-03-19 01:38:40 UTC
(In reply to Martin Mokrejš from comment #16)

i'm not sure hosts.allow matters ... if you've allowed sshd, then not supporting tcp-wrappers means it's allowed implicitly

the space is irrelevant -- look at the regex closer and the use of *
Comment 18 Martin Mokrejš 2015-03-19 09:27:38 UTC
(In reply to SpanKY from comment #17)
> (In reply to Martin Mokrejš from comment #16)
> 
> i'm not sure hosts.allow matters ... if you've allowed sshd, then not
> supporting tcp-wrappers means it's allowed implicitly
> 
> the space is irrelevant -- look at the regex closer and the use of *

But the check you have crafted does not get triggered if user has no hosts.deny but has hosts.allow (as the allow also allows for same functionality if the last column contain word 'deny').
Comment 19 SpanKY gentoo-dev 2015-03-20 02:35:31 UTC
Commit message: Also check /etc/hosts.allow for tcp-wrappers
http://sources.gentoo.org/net-misc/openssh/openssh-6.8_p1-r1.ebuild?r1=1.4&r2=1.5
Comment 20 Arfrever Frehtes Taifersar Arahesis 2015-03-20 15:50:28 UTC
(In reply to SpanKY from comment #19)
> @@ -98,4 +98,4 @@
>         # Make sure people who are using tcp wrappers are notified of its removal. #531156
> -       if grep -qs '^ *sshd *:' "${EROOT}"/etc/hosts.deny ; then
> +       if grep -qs '^ *sshd *:' "${EROOT}"/etc/hosts.{allow,deny} ; then
>                 eerror "Sorry, but openssh no longer supports tcp-wrappers, and it seems like"
>                 eerror "you're trying to use it.  Update your ${EROOT}etc/hosts.deny please."

This eerror message could also mention /etc/hosts.allow.
Comment 21 SpanKY gentoo-dev 2015-03-22 06:54:13 UTC
Commit message: Also note hosts.allow in the error message
http://sources.gentoo.org/net-misc/openssh/openssh-6.8_p1-r1.ebuild?r1=1.5&r2=1.6
Comment 22 Martin Mokrejš 2015-03-29 12:44:42 UTC
So I finally got to check what is the current status:

 * Messages for package net-misc/openssh-6.7_p1:

 * Remember to merge your config files in /etc/ssh/ and then
 * reload sshd: '/etc/init.d/sshd reload'.
 * Note: openssh-6.7 versions no longer support USE=tcpd as upstream has
 *       dropped it.  Make sure to update any configs that you might have.


Hmm, it doesn't help. The point is not to force users to adjust and ignore their old settings, blacklisted or white-listed IPs, etc. 

It doesn't point to this bug #531156 either.

It doesn't mention the only meaningful workaround is to:
  emerge -uN xinetd
  rc-update del sshd
  rc-update add xinetd default
  cp -p /etc/xinetd.d/rsh /etc/xinetd.d/ssh
  sed -e 's#in.rshd#sshd#' -i /etc/xinetd.d/ssh
  sed -e 's#disable.*= yes#disable\t= no#' -i /etc/xinetd.d/ssh
  /etc/init.d/sshd stop
  /etc/init.d/xinetd start


I still do not understand why Gentoo couldn't apply the patch like other distro's. There are other patches applied anyways.
Comment 23 Martin Mokrejš 2015-03-29 14:36:23 UTC
There are more tweaks needed,. Below I show how to run sshd on a non-default port. There are "-4 and -6" flags to sshd, probably they should be used in sync with "IPv4 and IPv6 values" in xinetd.conf. They cannot be used together at once, maybe two separate /etc/xinetd.d/{ssh_ipv4,ssh_ipv6} files could give you the IPv4 and IPv6 functionality back. The below works for me on an ipv4-only host.


# cat  /etc/xinetd.d/ssh2
service ssh2
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        group           = tty
        server          = /usr/sbin/sshd
        server_args     = -i -f /etc/ssh/sshd_config
        log_on_success  = PID HOST USERID EXIT DURATION
        log_on_failure  = HOST USERID ATTEMPT
        disable         = no
}
#

Make sure you add the ssh2 to /etc/services, that is where xinetd gets the port number from for the "service *ssh2*".

Then, enable xinetd to accept connection from other sources then just localhost. You cannot add all IP ranges easily, so just comment out the following line in /etc/xinetd.conf and let tcp-wrappers to kick in.

only_from       = localhost



Thanks to the "sshd -i" I have to wait about 45sec to get an answer from sshd which has to generate a new key before that. So, the xinetd-based workaround isn't an ideal.


Next time I better patch the openssh sources on my own.
Comment 24 SpanKY gentoo-dev 2015-03-29 15:41:45 UTC
(In reply to Martin Mokrejš from comment #22)

please read the bug.  the `die` is in 6.8, and adding the patch is not free.
Comment 25 Martin Mokrejš 2015-04-01 15:28:08 UTC
(In reply to SpanKY from comment #24)
> (In reply to Martin Mokrejš from comment #22)
> 
> please read the bug.  the `die` is in 6.8, and adding the patch is not free.

Aha, I thought that you also updated in sync the 6.7 as mentioned initially in comment #9. I see the elog lines in 6.7*.ebuild are different compared to 6.8*.ebuild. Thanks at least for what you did so far.
Comment 26 Martin Mokrejš 2015-04-16 09:17:21 UTC
>>> Emerging (1 of 38) net-misc/openssh-6.8_p1-r4::gentoo
 * openssh-6.8p1.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                                                                                                                                                                                            [ ok ]
 * openssh-6.8_p1-sctp.patch.xz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                                                                                                                                                                                    [ ok ]
 * openssh-6.8p1-r4-hpnssh14v5.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                                                                                                                                                                              [ ok ]
 * Sorry, but openssh no longer supports tcp-wrappers, and it seems like
 * you're trying to use it.  Update your /etc/hosts.{allow,deny} please.
 * ERROR: net-misc/openssh-6.8_p1-r4::gentoo failed (setup phase):
 *   USE=tcpd no longer works
 * 
 * Call stack:
 *                  ebuild.sh, line  93:  Called pkg_setup
 *   openssh-6.8_p1-r4.ebuild, line 102:  Called die
 * The specific snippet of code:
 *              die "USE=tcpd no longer works"
 * 



The above means I cannot use 6.8 with the sub-optimal xinetd-based workaround, which starts opensshd on the dedicated port if the service meets existing criteria in /etc/hosts.{allow,deny} files.

[ebuild   R    ] sys-apps/xinetd-2.3.15-r1::gentoo  USE="perl tcpd -rpc" 0 KiB


Dropping the lines mentioning ssh from the files is not a solution anyway. 

Maybe adding IUSE=xinetd to openssh could help:
- to install ready made /etc/xinetd.d/ssh files (seems one for IPv4 and one for IPv6)
- to shutdown this hard error call
Comment 27 cilly 2015-07-19 06:04:01 UTC
(In reply to SpanKY from comment #15)
> (In reply to Martin Mokrejš from comment #14)
> 
> i've added a check to 6.8p1 ... lets see who complains ;)
>   if grep -qs '^ *sshd *:' "${EROOT}"/etc/hosts.deny ; then
>     ...die...
>   fi

@SpanKY

Why die and not just a warning? It does not break opensshd if you have an entry in hosts.{allow,deny}
Comment 28 Thomas Beutin 2015-07-27 12:37:41 UTC
(In reply to cilly from comment #27)
> (In reply to SpanKY from comment #15)
[...]
> @SpanKY
> 
> Why die and not just a warning? It does not break opensshd if you have an
> entry in hosts.{allow,deny}

i'd like to have a warning only too, because this would support a setup like:
- sshd listens only to 127.0.0.1:22
- a xinetd service doing the following:
  * listening on the public IP address port 22
  * redirect every connection to 127.0.0.1:22
  * name the the service "sshd" (which in fact it is)

Or maybe adding an env var like SSHD_INIT_I_KNOW_WHAT_I_AM_DOING ?
Comment 29 SpanKY gentoo-dev 2015-08-12 07:19:34 UTC
*** Bug 555316 has been marked as a duplicate of this bug. ***
Comment 30 SpanKY gentoo-dev 2015-08-12 07:22:04 UTC
(In reply to Thomas Beutin from comment #28)
> (In reply to cilly from comment #27)
> > (In reply to SpanKY from comment #15)
> [...]
> > @SpanKY
> > 
> > Why die and not just a warning? It does not break opensshd if you have an
> > entry in hosts.{allow,deny}
> 
> i'd like to have a warning only too, because this would support a setup like:
> - sshd listens only to 127.0.0.1:22
> - a xinetd service doing the following:
>   * listening on the public IP address port 22
>   * redirect every connection to 127.0.0.1:22
>   * name the the service "sshd" (which in fact it is)
> 
> Or maybe adding an env var like SSHD_INIT_I_KNOW_WHAT_I_AM_DOING ?
Comment 31 SpanKY gentoo-dev 2015-08-12 07:22:47 UTC
(In reply to Thomas Beutin from comment #28)

i've relaxed it to a warning now:
http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3581b2c101337dec32c2bd6779db7927ff96732a

it probably caught the majority of people who cared at this point.
Comment 32 Martin Mokrejš 2015-09-07 06:39:06 UTC
There is also an ebuild patch included in https://forums.gentoo.org/viewtopic-t-1024270.html .