Bug 78325

Summary:	-current behaves differently than 4.X w.r.t rsh from security/krb5 port
Product:	Ports & Packages	Reporter:	Tillman Hodgson <tillman>
Component:	Individual Port(s)	Assignee:	Cy Schubert <cy>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Latest
Hardware:	Any
OS:	Any

Description Tillman Hodgson 2005-03-02 19:50:02 UTC

Note: I originally posted this problem to freebsd-ports@ on Nov 23 2004, with a followup to current@ on Dec 14 2004. The problem still exists in -current with src from as recent as March 01 2005 so I figured I'd file a PR so that the issue can be properly tracked.

I run a couple of Kerberos realms. in late 2004 I installed some new 5.3R machines and then immediately upgraded them to -current. Cursory testing seemed to show that the MIT Kerberos port (security/krb5) was working correctly. Over time, I've found a regression between it and my older 4.X systems (of which I have only remaining).

While kinit, kdestroy, klist, kerberos telnet and ftp, and other basic Kerberos-enabled tools work correctly, the kerberos rsh client (not the server, it's fine) doesn't work on -current.

Here's a a 4-stable box connecting via rsh to another 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, in thsi case a sparc64 one).

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 other 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 confirmed that inetd.conf is set up identically between the 4.X and the -current sysetms for the kshd line.

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 running 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

I've confirmed that this issue exists for every -current box that I've run across (I run 4 myself).

The problem is particularly vexing because Kerberos rsh is commonly used for securing "cluster" type operations (rmt for remote central backups, the clusterit port, central management scripting, etc).

How-To-Repeat:

Install security/krb5 port (the MIT Kerberos port) on a -current system. Try to use the rsh client that it installs. Compare with the results on a 4.X system.

I have a good working knowledge of Kerberos and I'm willing to do testing across a variety of systems if someone wants to test a potential fix :-)

Comment 1 Volker Stolz freebsd_committer

2005-03-03 16:36:05 UTC

Responsible Changed
From-To: freebsd-ports-bugs->cy

Over to maintainer

Comment 2 Tillman Hodgson 2005-03-11 19:40:44 UTC

Followup:

I've confirmed that the Heimdal port doesn't exhibit this behaviour --
Kerberos rsh/rshd works fine there. Note that this is the Heimdal port I
tested, the Heimdal in the base OS doesn't have the Kerberos bits in
rsh.

Comment 3 Cy Schubert 2005-03-11 20:19:01 UTC

I've been tracking this since December. No fix yet though. I have noticed 
that the server attempts to connect to a port on the client that is not (or 
no longer) open.


Cheers,
Cy Schubert <Cy.Schubert@komquats.com>
Web:  http://www.komquats.com and http://www.bcbodybuilder.com
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
BC Government:  <Cy.Schubert@gems8.gov.bc.ca>

    "Lift long enough and I believe arrogance is replaced by
    humility and fear by courage and selfishness by generosity
    and rudeness by compassion and caring."
        -- Dave Draper

Comment 4 Tillman Hodgson 2005-03-11 21:08:17 UTC

On Fri, Mar 11, 2005 at 12:19:01PM -0800, Cy Schubert wrote:
> I've been tracking this since December. No fix yet though. I have noticed 
> that the server attempts to connect to a port on the client that is not (or 
> no longer) open.

Thanks for tracking this, Cy.

My workaround in the meantime has been to install MIT krb5 to
/usr/local/krb5 and install the Heimdal port to /usr/local ... and I'm
using Heimdal solely for rshd. I'd like to be able to jettison one of
the redundant ports.

Playing with Heimdal in conjunction with MIT and trying all the
combinations gives the following results .,.

FreeBSD -current Heimdal port client to FreeBSD 4.x MIT kshd:
$ /usr/local/bin/rsh athena uptime
 2:47PM  up 82 days, 22:38, 4 users, load averages: 0.00, 0.00, 0.05

FreeBSD -current Heimdal port client to FreeBSD 4.x MIT kshd (with encryption):
$ /usr/local/bin/rsh -x athena uptime
rsh: decrypting data: Decrypt integrity check failed

FreeBSD -current Heimdal port client to FreeBSD -current Heimdal port rshd:
$ /usr/local/bin/rsh thoth uptime
 2:53PM  up 9 days,  3:22, 3 users, load averages: 0.03, 0.07, 0.07

FreeBSD -current Heimdal port client to FreeBSD -current Heimdal port rshd
(with encryption):
$ /usr/local/bin/rsh -x thoth uptime
 2:53PM  up 9 days,  3:23, 3 users, load averages: 0.01, 0.06, 0.07

FreeBSD 4.x MIT port client to FreeBSD 4.x MIT kshd:
[root@athena ~]# rsh athena uptime
 2:48PM  up 82 days, 22:39, 4 users, load averages: 0.00, 0.00, 0.04

FreeBSD 4.x MIT port client to FreeBSD 4.x MIT kshd (with encryption):
[root@athena ~]# rsh athena -x uptime
This rsh session is encrypting input/output data transmissions.
 2:50PM  up 82 days, 22:42, 4 users, load averages: 0.01, 0.00, 0.03

FreeBSD 5.x MIT port client to FreeBSD 4.x MIT kshd:
$ /usr/local/krb5/bin/rsh athena uptime
socket: protocol error or closed connection in circuit setup

FreeBSD 5.x MIT port client to FreeBSD 4.x MIT kshd (using encryption):
$ /usr/local/krb5/bin/rsh -x athena uptime
socket: protocol error or closed connection in circuit setup

So aside from the MIT on 5.x -> anything rsh problems, there also
appears to be an encrypted rsh problem (`rsh -x`) between Heimdal and
MIT (regardless of FreeBSD version). Since i only have 1 FreeBSD 4.x
host, I've just been ignoring that problem.

I took some tcpdumps of working a Heimdal on 5.x to Heimdal on 5.x rsh
connection and a non-working MIT connection. If they'd be helpful, you
can find them at
http://www.seekingfire.com/projects/kerberos/tmp/tcpdumps.html. I can
also make some ktrace information available if you'd find that useful.

-T

-- 
``These days, thinking someone is out to get you isn't paranoia, it's
  reality.  Lots of people are out to get you.  Paranoia is thinking
  they're all conspiring together.''
    -- Unknown

Comment 5 Cy Schubert freebsd_committer

2005-09-16 19:02:29 UTC

State Changed
From-To: open->closed

As of the latest 5-STABLE and 6-CURRENT, this is no longer a problem. Closing.