[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nifty control over S/Key usage
This is pretty much exactly Wietse Venema's logdaemon package's
login program. There are a number of limitations with it.
1) You may not want to support JUST skey, you may also want kerberos
and a challenge response (there is a logdaemon alternative for DES
chal/resp devices submitted by Bill LeFebre).
2) If you use anything else (like wu-ftpd with skey), you use the same
config file. This may/maynot be desirable.
I'd LIKE to say (of the top of my head),
"for network INSIDE, allow plain passwords ALWAYS"
"for service DEFAULT; use skey"
"for telnet, user=Bob, use snk" (secure net key, a des device)
"for ftp, user Bob, use kerberos"
Reasonable solutions are something like BSDi and FreeBSD's
login.conf, which can say "try kerberos, then skey, then snk"
for auth.
I had hacked the logdaemon's login to use the TIS FWTK
authentication daemon, sort of. Then the user management hit
"tis.access" and if it wanted extra auth (more than a plain
password), it used the Authdaemon, which supports s/key and SNK
and plain. I'm not really satisfied with it; I'd like to pass
the service (telnet/ftp/http?) and also allow kerberos IV or 5
tickets. It *is* nice in that you can have 1 authdaemon on one
machine and have many machines auth against that.
Again, no ideals, but I think the login.conf type solution
(and/or a whole PAM implementation?) allows us the most
flexibility.
Okay, now you all can say how stupid I am and what a bad idea this is.
chuck
Quoting Matthew Patton (patton@sysnet.net):
> FreeBSD has this nifty file /etc/skey.access which influences login's
> behavior. I didn't see it mentioned in the OpenBSD docs. Anyone interested?
>
> <begin quote>
> The configuration file /etc/skey.access can be used to configure
> restrictions on the use of UNIX passwords based
> on the host name, user name, terminal port, or IP address of a login
> session. The complete format of the file is
> documented in the skey.access(5) manual page; there are also some security
> cautions there which should be read
> before depending on this file for security.
>
> If there is no /etc/skey.access file (which is the default state as FreeBSD
> is shipped), then all users will be