krb5 port: -current behaves differently than 4.X w.r.t rsh

[Tillman Hodgson]

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 at 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 at athena.seekingfire.prv:/usr/obj/usr/src/sys/COYOTE  i386

[root at 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 at 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 at backforty# ipfw list
ipfw: getsockopt(IP_FW_GET): Protocol not available
root at backforty# ipfstat -hin
open: No such file or directory
root at 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)