From owner-freebsd-questions Fri Jun 28 18: 7:36 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5714637B405 for ; Fri, 28 Jun 2002 18:07:03 -0700 (PDT) Received: from mail.XtremeDev.com (xtremedev.com [216.241.38.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61EAB43E09 for ; Fri, 28 Jun 2002 18:07:02 -0700 (PDT) (envelope-from freebsd@XtremeDev.com) Received: from xtremedev.com (xtremedev.com [216.241.38.65]) by mail.XtremeDev.com (Postfix) with ESMTP id CBD4C70601 for ; Fri, 28 Jun 2002 19:06:55 -0600 (MDT) Date: Fri, 28 Jun 2002 19:06:55 -0600 (MDT) From: FreeBSD user To: questions@freebsd.org Subject: OpenSSH 3.4p1_1 and reverse ip Message-ID: <20020628190401.E7121-200000@Amber.XtremeDev.com> MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="0-1747156543-1025233169=:6604" Content-ID: <20020628190401.D7121@Amber.XtremeDev.com> Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1747156543-1025233169=:6604 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20020628190401.Q7121@Amber.XtremeDev.com> After installing OpenSSH 3.4p1_1-portable (overwriting the one in base with -DOPENSSH_OVERWRITE_BASE) and restarting it, /usr/sbin/sshd keeps taking ~3-~5 minutes trying to reverse/resolve connecting client ips, even though I specifically told it not to in /etc/ssh/sshd_config. On top of which, the connecting ip IS reversable, I've checked with nslookup. Attached is my sshd_config. Another of note, I'm not using BIND, I'm using djbdns, both tinydns and dnscache on the box running the sshd. ~> nslookup 192.168.1.2 Server: ns.xtremedev.com Address: 192.168.1.1 Name: work.xtremedev.com Address: 192.168.1.2 ~> sudo /usr/sbin/sshd -d -d -d debug1: sshd version OpenSSH_3.4p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Server will not fork when running in debugging mode. Connection from 192.168.1.2 port 2737 debug1: Client protocol version 2.0; client software version PuTTY-Release-0.52 debug1: no match: PuTTY-Release-0.52 Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1 debug2: Network child is on pid 16762 debug3: privsep user:group 22:22 debug3: preauth child monitor started debug1: list_hostkey_types: ssh-rsa,ssh-dss debug3: mm_request_receive entering debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes256-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se,aes192-cbc,rijndael192-cbc,aes128-cbc,rijndael128-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: aes256-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se,aes192-cbc,rijndael192-cbc,aes128-cbc,rijndael128-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,none debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,none debug2: kex_parse_kexinit: none,zlib,none debug2: kex_parse_kexinit: none,zlib,none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-sha1 debug1: kex: client->server aes256-cbc hmac-sha1 none debug2: mac_init: found hmac-sha1 debug1: kex: server->client aes256-cbc hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received debug3: mm_request_send entering: type 0 debug3: monitor_read: checking request 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_answer_moduli: got parameters: 1024 2048 8192 debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: mm_request_send entering: type 1 debug3: mm_choose_dh: remaining 0 debug2: monitor_read: 0 used once, disabling now debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug3: mm_request_receive entering debug1: dh_gen_key: priv key bits set: 259/512 debug1: bits set: 994/2049 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1062/2049 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug3: mm_answer_sign: signature 0x80a4c00(527) debug3: mm_request_send entering: type 5 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: cipher_init: set keylen (16 -> 32) debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug1: newkeys: mode 0 debug1: cipher_init: set keylen (16 -> 32) debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug3: Trying to reverse map address 192.168.1.2. Could not reverse map address 192.168.1.2. You can see from ^^^^^^ (when I connect from my internal machine at 192.168.1.2, work.xtremedev.com) it can't resolve this. I have all my firewall rules turned off (pass all) and name server running (djbdns). nslookup is able to resolve the ip. But for some reason sshd can't. I even explicitly told sshd not to reverse ip in /etc/ssh/sshd_config: VerifyReverseMapping no Can anyone see what I've missed? The client is able to connect successfully after the elapsed time, it's just that horrid wait that the user has to endure. If it wasn't for the exploit, I would immediately backcvs to use the one that came with base rather than using the 3.4p1_1 port. Thanks --0-1747156543-1025233169=:6604 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=sshd_config Content-Transfer-Encoding: BASE64 Content-ID: <20020628190655.L7121@Amber.XtremeDev.com> Content-Description: Content-Disposition: attachment; filename=sshd_config IwkkT3BlbkJTRDogc3NoZF9jb25maWcsdiAxLjU2IDIwMDIvMDYvMjAgMjM6 Mzc6MTIgbWFya3VzIEV4cCAkDQoNCiMgVGhpcyBpcyB0aGUgc3NoZCBzZXJ2 ZXIgc3lzdGVtLXdpZGUgY29uZmlndXJhdGlvbiBmaWxlLiAgU2VlDQojIHNz aGRfY29uZmlnKDUpIGZvciBtb3JlIGluZm9ybWF0aW9uLg0KDQojIFRoaXMg c3NoZCB3YXMgY29tcGlsZWQgd2l0aCBQQVRIPQ0KDQojIFRoZSBzdHJhdGVn eSB1c2VkIGZvciBvcHRpb25zIGluIHRoZSBkZWZhdWx0IHNzaGRfY29uZmln IHNoaXBwZWQgd2l0aA0KIyBPcGVuU1NIIGlzIHRvIHNwZWNpZnkgb3B0aW9u cyB3aXRoIHRoZWlyIGRlZmF1bHQgdmFsdWUgd2hlcmUNCiMgcG9zc2libGUs IGJ1dCBsZWF2ZSB0aGVtIGNvbW1lbnRlZC4gIFVuY29tbWVudGVkIG9wdGlv bnMgY2hhbmdlIGENCiMgZGVmYXVsdCB2YWx1ZS4NCg0KUG9ydCAyMg0KUHJv dG9jb2wgMg0KI0xpc3RlbkFkZHJlc3MgMC4wLjAuMA0KI0xpc3RlbkFkZHJl c3MgOjoNCg0KIyBIb3N0S2V5IGZvciBwcm90b2NvbCB2ZXJzaW9uIDENCkhv c3RLZXkgL2V0Yy9zc2gvc3NoX2hvc3Rfa2V5DQojIEhvc3RLZXlzIGZvciBw cm90b2NvbCB2ZXJzaW9uIDINCkhvc3RLZXkgL2V0Yy9zc2gvc3NoX2hvc3Rf cnNhX2tleQ0KSG9zdEtleSAvZXRjL3NzaC9zc2hfaG9zdF9kc2Ffa2V5DQoN CiMgTGlmZXRpbWUgYW5kIHNpemUgb2YgZXBoZW1lcmFsIHZlcnNpb24gMSBz ZXJ2ZXIga2V5DQpLZXlSZWdlbmVyYXRpb25JbnRlcnZhbCAzNjAwDQpTZXJ2 ZXJLZXlCaXRzIDQwOTYNCg0KIyBMb2dnaW5nDQojb2Jzb2xldGVzIFF1aWV0 TW9kZSBhbmQgRmFzY2lzdExvZ2dpbmcNClN5c2xvZ0ZhY2lsaXR5IEFVVEgN CkxvZ0xldmVsIElORk8NCg0KIyBBdXRoZW50aWNhdGlvbjoNCg0KTG9naW5H cmFjZVRpbWUgNjAwDQpQZXJtaXRSb290TG9naW4gbm8NClN0cmljdE1vZGVz IHllcw0KDQpSU0FBdXRoZW50aWNhdGlvbiB5ZXMNCiNQdWJrZXlBdXRoZW50 aWNhdGlvbiB5ZXMNCiNBdXRob3JpemVkS2V5c0ZpbGUJLnNzaC9hdXRob3Jp emVkX2tleXMNCg0KIyByaG9zdHMgYXV0aGVudGljYXRpb24gc2hvdWxkIG5v dCBiZSB1c2VkDQpSaG9zdHNBdXRoZW50aWNhdGlvbiBubw0KIyBEb24ndCBy ZWFkIHRoZSB1c2VyJ3Mgfi8ucmhvc3RzIGFuZCB+Ly5zaG9zdHMgZmlsZXMN Cklnbm9yZVJob3N0cyB5ZXMNCiMgRm9yIHRoaXMgdG8gd29yayB5b3Ugd2ls bCBhbHNvIG5lZWQgaG9zdCBrZXlzIGluIC9ldGMvc3NoL3NzaF9rbm93bl9o b3N0cw0KI1Job3N0c1JTQUF1dGhlbnRpY2F0aW9uIG5vDQojIHNpbWlsYXIg Zm9yIHByb3RvY29sIHZlcnNpb24gMg0KSG9zdGJhc2VkQXV0aGVudGljYXRp b24gbm8NCiMgQ2hhbmdlIHRvIHllcyBpZiB5b3UgZG9uJ3QgdHJ1c3Qgfi8u c3NoL2tub3duX2hvc3RzIGZvcg0KIyBSaG9zdHNSU0FBdXRoZW50aWNhdGlv biBhbmQgSG9zdGJhc2VkQXV0aGVudGljYXRpb24NCiNJZ25vcmVVc2VyS25v d25Ib3N0cyBubw0KDQojIFRvIGRpc2FibGUgdHVubmVsZWQgY2xlYXIgdGV4 dCBwYXNzd29yZHMsIGNoYW5nZSB0byBubyBoZXJlIQ0KI1Bhc3N3b3JkQXV0 aGVudGljYXRpb24geWVzDQojUGVybWl0RW1wdHlQYXNzd29yZHMgbm8NCg0K IyBDaGFuZ2UgdG8gbm8gdG8gZGlzYWJsZSBzL2tleSBwYXNzd29yZHMNCkNo YWxsZW5nZVJlc3BvbnNlQXV0aGVudGljYXRpb24geWVzDQoNCiMgS2VyYmVy b3Mgb3B0aW9ucw0KI0tlcmJlcm9zQXV0aGVudGljYXRpb24gbm8NCiNLZXJi ZXJvc09yTG9jYWxQYXNzd2QgeWVzDQojS2VyYmVyb3NUaWNrZXRDbGVhbnVw IHllcw0KDQojQUZTVG9rZW5QYXNzaW5nIG5vDQoNCiMgS2VyYmVyb3MgVEdU IFBhc3Npbmcgb25seSB3b3JrcyB3aXRoIHRoZSBBRlMga2FzZXJ2ZXINCiNL ZXJiZXJvc1RndFBhc3Npbmcgbm8NCg0KIyBTZXQgdGhpcyB0byAneWVzJyB0 byBlbmFibGUgUEFNIGtleWJvYXJkLWludGVyYWN0aXZlIGF1dGhlbnRpY2F0 aW9uIA0KIyBXYXJuaW5nOiBlbmFibGluZyB0aGlzIG1heSBieXBhc3MgdGhl IHNldHRpbmcgb2YgJ1Bhc3N3b3JkQXV0aGVudGljYXRpb24nDQojUEFNQXV0 aGVudGljYXRpb25WaWFLYmRJbnQgeWVzDQoNClgxMUZvcndhcmRpbmcgeWVz DQpYMTFEaXNwbGF5T2Zmc2V0IDEwDQojWDExVXNlTG9jYWxob3N0IHllcw0K UHJpbnRNb3RkIHllcw0KUHJpbnRMYXN0TG9nIHllcw0KS2VlcEFsaXZlIHll cw0KVXNlTG9naW4gbm8NClVzZVByaXZpbGVnZVNlcGFyYXRpb24geWVzDQpD b21wcmVzc2lvbiB5ZXMNCg0KIyBBZnRlciAxMCB1bmF1dGhlbnRpY2F0ZWQg Y29ubmVjdGlvbnMsIHJlZnVzZSAzMCUgb2YgdGhlIG5ldyBvbmVzLCBhbmQN CiMgcmVmdXNlIGFueSBtb3JlIHRoYW4gNjAgdG90YWwuDQpNYXhTdGFydHVw cyAxMDozMDo2MA0KIyBubyBkZWZhdWx0IGJhbm5lciBwYXRoDQojQmFubmVy IC9zb21lL3BhdGgNClZlcmlmeVJldmVyc2VNYXBwaW5nIG5vDQoNCkdhdGV3 YXlQb3J0cyB5ZXMNCg0KIyBvdmVycmlkZSBkZWZhdWx0IG9mIG5vIHN1YnN5 c3RlbXMNClN1YnN5c3RlbQlzZnRwCS91c3IvbGliZXhlYy9zZnRwLXNlcnZl cg0K --0-1747156543-1025233169=:6604-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message