Your message dated Tue, 21 Feb 2006 09:12:58 +0000 with message-id <[EMAIL PROTECTED]> and subject line Bug#310536: status? has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
--- Begin Message ---Package: ssh Version: 1:3.8.1p1-8.sarge.4 Severity: normal May 24 08:00:04 gaia sshd[29447]: reverse mapping checking getaddrinfo for 122.69-93-144.reverse.theplanet.com failed - POSSIBLE BREAKIN ATTEMPT! You will have to agree with me that this is a little over the top, no? Plenty of ISPs can't even spell DNS, and I don't see why a failed reverse lookup can be any indication. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (600, 'testing'), (98, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11-cirrus Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages ssh depends on: ii adduser 3.63 Add and remove users and groups ii debconf 1.4.45 Debian configuration management sy ii dpkg 1.10.27 Package maintenance system for Deb ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra ii zlib1g 1:1.2.2-4 compression library - runtime -- debconf information excluded -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! "was aus liebe getan wird, geschieht immer jenseits von gut und böse." - friedrich nietzsche
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---tags 310536 wontfix thanks On Tue, Feb 21, 2006 at 09:33:36AM +0100, martin f krafft wrote: > If you can take a minute to fill me in on the status of this bug > report, it would be greatly appreciated! (If there were any progress, it would already be in the bug log ...) Anyway, upon investigation I don't think this is a bug. Your description of the situation as "failed reverse resolution" is not accurate, or at least is somewhat misleading; this warning is *not* issued when reverse DNS resolution of your IP address merely fails outright. What has happened is that sshd has looked up the IP address you gave and got "122.69-93-144.reverse.theplanet.com" back, but then failed to confirm that 122.69-93-144.reverse.theplanet.com is really an address of that host. As the source code says: /* * Map it back to an IP address and check that the given * address actually is an address of this host. This is * necessary because anyone with access to a name server can * define arbitrary names for an IP address. Mapping from * name to IP address can be trusted better (but can still be * fooled if the intruder has access to the name server of * the domain). */ In other words, imagine that I know that you frequently ssh to this host from friendlyhost.example.org. I publish a PTR record for my IP address, let's say 1.2.3.4 (I can do this wherever I like; it works better if I've gained access to your ISP's nameserver) claiming that it's friendlyhost.example.org; I don't have to have access to example.org's DNS to do this. Now take away this sshd check, and as far as sshd is concerned I'm friendlyhost.example.org. While sshd almost always combines information from DNS with public key checks, the DNS checks are still useful, particularly when looking through logs afterwards for evidence of an attack; for instance, it's common to use from= restrictions in authorized_keys files to make sure that even if somebody steals the key then they can't log in from anywhere in the world (see sshd(8) for commentary). I don't feel inclined to weaken these checks. Cheers, -- Colin Watson [EMAIL PROTECTED]
--- End Message ---
