From owner-freebsd-current@FreeBSD.ORG Tue Dec 21 21:10:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEB3116A4CE for ; Tue, 21 Dec 2004 21:10:09 +0000 (GMT) Received: from mail.seekingfire.com (caliban.rospa.ca [24.72.10.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5101B43D1D for ; Tue, 21 Dec 2004 21:10:09 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id BDE2521C; Tue, 21 Dec 2004 15:10:08 -0600 (CST) Date: Tue, 21 Dec 2004 15:10:08 -0600 From: Tillman Hodgson To: FreeBSD -CURRENT Message-ID: <20041221211008.GB2641@seekingfire.com> References: <20041214165144.GJ17907@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041214165144.GJ17907@seekingfire.com> 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: Re: krb5 port: -current behaves differently than 4.X w.r.t rsh (possibly EPERM from bind) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 21:10:10 -0000 On Tue, Dec 14, 2004 at 10:51:44AM -0600, Tillman Hodgson wrote: > Howdy folks, > > I'm this on trying on -current@ to see if I can work with someone here to > get this problem trouble-shot and fixed. I'm still trying to resolve this proble. I have a ktrace.dump available (using `ktrace -di rsh -x -d athena uptime`), but it doesn't seem to show anything out of the ordinary. I'm not very proficient with ktrace and kdump, however. For instance, I didn't see the socket operations ... I imagien that takes place in a library and simply wasn't captured. I also have a tcpdump capture. It looks like the connect to port kshell passes the 3-way handshake. This is where things get weird. The kshd host sends a new SYN back to the client on the client's source port + 1. The client sends a reset packet back to the host (it seems it's not listening there). The host then sends a FIN to the original source port, closing off the original connection attempt. I'm not sure what the connect-back is all about ... Any ideas out there? I'd really like to get the Kerberos rsh client working on a 5.X system. -T > Date: Tue, 23 Nov 2004 16:00:09 -0600 > From: Tillman Hodgson > Subject: krb5 port: -current behaves differently than 4.X w.r.t rsh > To: FreeBSD-Ports > > 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?