Just some notes about the subject. I want to remind that usually /bin/login will retry login attempt in case first one failed. And this can be very surprizing. I will give example with plain telnet, not kerberized one: machine1$ telnet machine2 -l scott Telnet: trying... Password: <blah blah blah> (place your favorite invalid password here) (some delay usually goes here) Login incorrect. login: fred <<< note note note note Password: <fred's password> machine2 fred $ _ Ok: I requested to login as scott, but lately entered "fred" as username and fred's password. I think that this situation is also possible with kerberized telnet, _especially_ when PAM concerned: if administrator rejects someone's access to the system (using pam_listfile etc etc), 1st login attempt will fail, and after this login will prompt for a username. But note that if that second username will be not the same as first one, we can have at least strange things with kerberos tickets (yes, if second time login will "fallback" to plain password auth): Fred on remote machine will have access to scott's tickets etc. I don't know well about kerberos environment, but think that things like this should be avioded specially. And the only reliable solution to this is to have login's functionality built-in to telnetd, so that it will have full control for tickets _and_ usernames. And one more note. It seemed to be very bad idea to store tickets somewhere in /tmp -- especially if we recall how many symlink attacks and similar things has been corrected last time. Home directory is better, but have other disadvantages, especially in case it is nfs-mounted (that is common practice). With nfs-mounted homedir there are a lot of problems anyway (pgp/ssh private keys that are passed via network in clear for example). Kerberos tickets are short-lived things (as I know of), so the best place for them is a shared memory. And I think that portablilty is _not_ a problem here. Most systems have shared memory concept today; them are _very_ different from each other -- yes, this _is_ a problem, that requires a lot of careful coding. But this problem was already solved many times in many packages. BTW, storing tickets in shared memory is good for many other places, and when only one machine involved (without telnet/etc), isn't it? Regards, Michael.