On one of my gentoo linux machines openssh ignores the "sshd: xxx.xxx.xxx.xxx" entries in /etc/deny.hosts (world-readable). I compiled openssh with tcpd USE-flag on, but it seems that it doesn't work. On a new installation it works, but vsftpd ignores the entries in hosts.deny (changed from "sshd:" to "ALL:") so it seems that something is wrong with tcp-wrappers or the programs. vsftpd: 2.0.4-r1 openssh: 4.4_p1-r6 tcp-wrappers: 7.6-r8
Please attach your hosts.allow and hosts.deny files Remember, hosts.allow is examined before hosts.deny and the first match is used.
hosts.allow is world-readable with 0 bytes hosts.deny is world-readable with entries of the form "sshd: 10.0.0.1" (10.0.0.1 for testing purposes), separated by newlines. They live in /etc on a xfs mount (mount option noatime)
Well, it Works For Me with hosts.deny sshd: 192.168.0.2 Change any part of the above and I can ssh in from 192.168.0.2, otherwise with the above line and no hosts.allow file it works. Maybe try removing hosts.allow completely? And I know vsftpd works with tcpd as I use it to load a special config for connections on a specific IP.
(In reply to comment #3) > sshd: 192.168.0.2 Like sshd: 10.0.0.1, I know it should look like this and it works on another computer if I do so, but not on this special one :-( > Maybe try removing hosts.allow completely? At first it didn't exist and as it didn't work I thought I should try to create it (didn't help as you see). > And I know vsftpd works with tcpd as I use it to load a special config for > connections on a specific IP. With ALL: 10.0.0.1 blocking doesn't work for me with vsftpd even on a new installation. Maybe I have missed some kernel setting? (I am using kernel 2.6.17-gentoo-r8 on a x86_64 computer). I am not blocking the wrong ip-address, because I only have one ethernet-controller on the computer which I tried to block for testing purposes.
you should post `emerge info` so we dont have to guess at your configuration you should also try rebuilding all affected apps with USE=-ipv6 to see if that changes anything
Portage 2.1.1-r1 (default-linux/amd64/2006.0, gcc-3.4.6, glibc-2.4-r4, 2.6.17-gentoo-r8 x86_64) ================================================================= System uname: 2.6.17-gentoo-r8 x86_64 Dual Core AMD Opteron(tm) Processor 265 Gentoo Base System version 1.12.6 Last Sync: Thu, 09 Nov 2006 03:20:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="" //here were my gentoo mirrors MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="" //here was my rsync mirror USE="amd64 acl apache2 berkdb bitmap-fonts cdr clamav cli cracklib crypt cups dlloader dri dvd dvdr eds elibc_glibc emboss encode fam foomaticdb ftp gd gif gpm gstreamer gtk2 iconv imlib input_devices_keyboard input_devices_mouse isdnlog java kerberos kernel_linux ldap lzw lzw-tiff mp3 mpeg ncurses nls nptl nptlonly oav pam pcre perl pic png pppd python qt3 qt4 quicktime readline reflection samba sdl session spell spl ssl tcpd tiff truetype-fonts type1-fonts usb userland_GNU userlocales video_cards_vesa xorg xpm zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY ACCEPT_KEYWORDS="amd64"
[ebuild R ] sys-apps/tcp-wrappers-7.6-r8 USE="-ipv6" 0 kB [ebuild R ] net-misc/openssh-4.4_p1-r6 USE="kerberos ldap pam tcpd -X -X509 -chroot -hpn -libedit (-selinux) -skey -smartcard -static" 0 kB
Thanks for the help until now. The sshd from openssh ignores the hosts.deny-file and I haven't found an option for this (yet). It would be very nice if somebody could help me to fix this, because this is my real problem (vsftpd was only for testing purposes if tcp_wrappers are working or not). vsftpd needs the tcp_wrappers=YES option set in its config file to work properly, tcpd is not activated automatically during emerge (although I think it would be a nice feature to activate it during etc-update if somebody compiles it with USE="tcpd" set). vsftpd blocks the hosts in hosts.deny (so tcp_wrappers seem to be not broken).
The problem was my sshd_config-file (sorry I didn't post it), the ListenAddress was commented. As a result sshd listened on the computer's ipv4 and ipv6 address. As tcp-wrappers were compiled without ipv6 support, the request was allowed (although the ipv4 address was in hosts.deny). I consider this as a bug, because as it was an ipv4-address and so it could be mapped from an ipv6 address to ipv4 and so it could have been checked. By the way there is no USE-Flag for ipv6 for the openssh package so I didn't know whether it was ipv6 enabled or not. I think there should be at least a warning (causing the compilation to abort) that tcpd-support will not work properly with an ipv6 enabled kernel and a non-ipv6 enabled tcp-wrappers package.
(In reply to comment #9) > I consider this as a bug, because as it was an ipv4-address and so it could be > mapped from an ipv6 address to ipv4 and so it could have been checked. Just because you can map an IPv4 address into an IPv6 address does not mean that the same IPv6 address is derived from an IPv4 address, so the check would not be 100% accurate. > I think there should be at least a warning (causing the compilation to abort) > that tcpd-support will not work properly with an ipv6 enabled kernel and a > non-ipv6 enabled tcp-wrappers package. Not going to happen. The ipv6 flag does exactly that, so if tcp wrappers isn't compiled for IPv6 then it will allow it through in the same way that it allows protocols through that is does not understand, like IPX. Maybe we need to document this better though as it applies to every package that uses the IPv6 flag afaik. Assigning to docs team :)
(In reply to comment #10) > (In reply to comment #9) > > I consider this as a bug, because as it was an ipv4-address and so it could be > > mapped from an ipv6 address to ipv4 and so it could have been checked. > > Just because you can map an IPv4 address into an IPv6 address does not mean > that the same IPv6 address is derived from an IPv4 address, so the check would > not be 100% accurate. > > > I think there should be at least a warning (causing the compilation to abort) > > that tcpd-support will not work properly with an ipv6 enabled kernel and a > > non-ipv6 enabled tcp-wrappers package. > > Not going to happen. > The ipv6 flag does exactly that, so if tcp wrappers isn't compiled for IPv6 > then it will allow it through in the same way that it allows protocols through > that is does not understand, like IPX. > > Maybe we need to document this better though as it applies to every package > that uses the IPv6 flag afaik. Assigning to docs team :) > So, what *exactly* would you like to see, and in *which* document?
(In reply to comment #10) Weeeeell . . . after discussing this with UberLord ("%$
(In reply to comment #10) Weeeeell . . . after discussing this with UberLord ("%$£^ &%$^*$^& 54"&%$&$%&% %% &%$&54&$%&%&&") on IRC ;), this really is beyond the scope of any Gentoo documentation we currently have. Best we can do is point you at http://www.openssh.com/ and suggest that you read up on the manuals there when you're trying something really tricky & detailed. This: "The problem was my sshd_config-file (sorry I didn't post it), the ListenAddress was commented. As a result sshd listened on the computer's ipv4 and ipv6 address." is user error, plain and simple, nothing we can do about it. :) This: "As tcp-wrappers were compiled without ipv6 support, the request was allowed (although the ipv4 address was in hosts.deny)." ". . .if tcp wrappers isn't compiled for IPv6 then it will allow it through in the same way that it allows protocols through that is does not understand, like IPX." is the planned design of the openssh package of the upstream authors; they wanted it to behave this way. Not a Gentoo bug. :)
