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
Reassigning this bug to package maintainers. This is not a security vulnerability that will be tracked by the Security team.
Sorry about bug-spam, forgot to uncheck "reset assignee to default"..
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
Ping? I don't want to be rude but this is rather important issue.
(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
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.
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
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.
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
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).
*** Bug 536076 has been marked as a duplicate of this bug. ***
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
(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" ?
(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.
(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
(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
(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 *
(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').
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
(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.
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
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.
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.
(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.
(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.
>>> 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
(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}
(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 ?
*** Bug 555316 has been marked as a duplicate of this bug. ***
(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 ?
(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.
There is also an ebuild patch included in https://forums.gentoo.org/viewtopic-t-1024270.html .