I don't know why Mark does not fix this. I have reported this
yet back in May, please see attached. While pam_rhosts_auth.so
is unavailable, I suggest we commit the following:
RCS file: /home/ncvs/src/etc/pam.conf,v
retrieving revision 1.19
diff -u -r1.19 pam.conf
--- pam.conf 2001/08/26 18:15:32 1.19
+++ pam.conf 2001/09/25 08:21:28
@@ -63,7 +63,8 @@
login password required pam_unix.so no_warn try_first_pass
rsh auth required pam_nologin.so no_warn
-rsh auth required pam_permit.so no_warn
+rsh auth required pam_deny.so no_warn
+#rsh auth required pam_rhosts_auth.so
rsh account required pam_unix.so
rsh session required pam_permit.so
On Tue, Sep 25, 2001 at 02:44:38PM +0930, Thyer, Matthew wrote:
> Why can I "rcp" to my FreeBSD-CURRENT box (built Sept 19th) with
> no password when I dont even have a .rhosts file (I dont have an
> /etc/hosts.equiv either).
> I can also "rsh freebie command" with no prompt for password.
> I assume this is due to the upgrade of PAM.
> Looking on a RedHat 7.1 system I see they have the following in
> # For root login to succeed here with pam_securetty, "rsh" must be
> # listed in /etc/securetty.
> auth required /lib/security/pam_nologin.so
> auth required /lib/security/pam_securetty.so
> auth required /lib/security/pam_env.so
> auth required /lib/security/pam_rhosts_auth.so
> account required /lib/security/pam_stack.so service=system-auth
> session required /lib/security/pam_stack.so service=system-auth
> My FreeBSD-CURRENT box has this for rsh:
> rsh auth required pam_nologin.so no_warn
> rsh auth required pam_permit.so no_warn
> rsh account required pam_unix.so
> rsh session required pam_permit.so
> It seems that we dont have a /usr/lib/pam_rhosts_auth.so.
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
--- Begin Message ---
> This is JFYI that the default (as given in /etc/pam.conf)
> PAM configuration for rshd(8) currently results in a root
> compromise, if rshd(8) is enabled in /etc/inetd.conf.
rshd is a root compromise anyway :-)
> It is obvious that "we can't have a conversation with the
> client over the rsh connection", but using pam_permit is
> certainly a bad idea.
> If this behavior was planned when committed, /etc/pam.conf
> should at least warn about this.
Agreed. I'll do that.
Warning: this .sig is umop ap!sdn
--- End Message ---