From owner-freebsd-ports@FreeBSD.ORG Tue Nov 23 22:00:10 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2908716A4CF for ; Tue, 23 Nov 2004 22:00:10 +0000 (GMT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD6FF43D58 for ; Tue, 23 Nov 2004 22:00:09 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 4CFCF144; Tue, 23 Nov 2004 16:00:09 -0600 (CST) Date: Tue, 23 Nov 2004 16:00:09 -0600 From: Tillman Hodgson To: FreeBSD-Ports Message-ID: <20041123220009.GJ88293@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/personal/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers X-Tillman-rules: yes he does User-Agent: Mutt/1.5.6i Subject: krb5 port: -current behaves differently than 4.X w.r.t rsh X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 22:00:10 -0000 Howdy folks, [I'm not sure that ports@ is the right place for this, but thought I'd start here and see what happens.] I run a couple of Kerberos realms. I recently installed some new 5.3R machines and then immediately upgraded them to -current. Cursory testing (I know, I know) seemed to show that the MIT Kerberos port (security/krb5) was working correctly. Over time, I've found a difference between it and my older 4.X systems. While kinit, kdestroy, klist, kerberos telnet and ftp, and other basic tools work correctly, the kerberos rsh client (not the server, it's fine) doesn't seem to work. Here's a a 4-stable box connecting via rsh to anotehr 4-stable box as well as to a -current box: [root@athena ~]# rsh -x coyote uname -a This rsh session is encrypting input/output data transmissions. FreeBSD coyote.seekingfire.com 4.10-STABLE FreeBSD 4.10-STABLE #0: Thu Nov 18 13:10:32 CST 2004 toor@athena.seekingfire.prv:/usr/obj/usr/src/sys/COYOTE i386 [root@athena ~]# rsh -x backforty uname -a This rsh session is encrypting input/output data transmissions. FreeBSD backforty.seekingfire.prv 6.0-CURRENT FreeBSD 6.0-CURRENT #2: Fri Nov 19 08:03:52 CST 2004 tillman@backforty.seekingfire.prv:/usr/obj/usr/src/sys/BACKFORTY i386 When I try to connect from the -current box ('backforty' from the example above) outwards to either type of box I get a failure: $ rsh -x coyote uptime socket: protocol error or closed connection in circuit setup $ rsh -x caliban uptime socket: protocol error or closed connection in circuit setup (caliban is another -current box). The auth.log on the server-side system shows: Nov 23 15:55:10 athena kshd[4565]: connect second port: Connection refused Note that all otehr client Kerberos apps work: I can telnet -x, ftp -x, rlogin, etc to my hearts connect. Only rsh displays this behaviour. I've confirmed that I'm running the right rsh binary: $ which rsh /usr/local/krb5/bin/rsh And I've confirmed that they're both running up-to-date ports trees and the most current version fo security/krb5. I've googled for the auth.log message. It seems that the connection "back" for stderr is being denied. By what, I don't know ... the host backforty isn't runnign any sort of firewall: root@backforty# ipfw list ipfw: getsockopt(IP_FW_GET): Protocol not available root@backforty# ipfstat -hin open: No such file or directory root@backforty# pfctl -s rules pfctl: /dev/pf: No such file or directory Any ideas? -T -- >I've gone through over-stressed to physical exhaustion... what's next? Tuesday - A.S.R. quote (Simon Burr & Kyle Hearn)