True. This is viewed as yet another security interlock/doublecheck.
> I have several users who I don't want to give shells to, but I do
> want to be able to dial in through my PM2's using UNIX-PW.
The presence of a line in /etc/shells does not mean you have to
"give shells to" them. The entry in the /etc/passwd file and the
/etc/shells file could be /bin/false (not a very useful shell!)
> I don't want to put /bin/false into /etc/shells !!
Oh. Well, nevermind... ;^)
> I kind of like the "Merit won't authenticate you if you don't have
> a 'valid' shell" thing, but I would like to be able to make exceptions
> to this rule, and allow certain no-shell users to be authenticated
> with UNIX-PW for termserver access thru RADIUS.
I take it my suggestion about the FILE authentication type was not
useful?
> To put it another way ... I see the shell thing as a UNIX specific
> mechanism for disallowing shell/ftp access. I'm not convinced that
> RADIUS should assume that if I don't want someone having shell access
> then I don't want them to have dialin PPP/SLIP access.
Well, all it was doing was authenticating them or not. After they
are authenticated, you can go through a whole 'nother set of steps
for authorization. The "A" in our LAS concept stands for authorization.
Then again, of course, you could write your own AATV... :-)
But seriously, we will have a general purpose authorization "hook"
in a future release, since so many people want a simple way to hang
local authorization checks onto their RADIUS server. And maybe the
AATV concept is too "heavy weight" for this. At least, I'd like to
do this...
Regards,
web...
-- William Bulley, N8NXN Senior Systems Research Programmer Merit Network Inc. Domain: web@merit.edu 4251 Plymouth Road MaBell: (313) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (313) 747-3185