|2)||Check authorization via the access-control files .k5login and .klogin in the users home directory.|
|3)||Prompt for password if any checks fail and the -p option was supplied.|
|If the authentication succeeds, login the user by calling the accompanying login.krb5.|
|klogind allows Kerberos V5 authentication with the .k5login access control file to be trusted. If this authorization check is passed, then the user is allowed to log in. If the user has no .k5login file, the login will be authorized if the results of krb5_aname_to_localname conversion matches the account name. Unless special rules are configured, this will be true if and only if the Kerberos principal of the connecting user is in the default local realm and the principal portion matches the account name.|
The configuration of klogind is done
by command line arguments passed by inetd. The options are:
Prompt the user for a password.
If the -P option is passed, then the password is verified in addition
to all other checks.
Create an encrypted session.
Require Kerberos V5 clients to present a cryptographic checksum of
initial connection information like the name of the user that the
client is trying to access in the initial authenticator. This
checksum provides additionl security by preventing an attacker from
changing the initial connection information. If this option is
specified, older Kerberos V5 clients that do not send a checksum in
the authenticator will not be able to authenticate to this server.
This option is mutually exclusive with the -i option.
If neither the -c or -i options are specified,then checksums are validated if presented. Since it is difficult to remove a checksum from an authenticator without making the authenticator invalid, this default mode is almost as significant of a security improvement as -c if new clients are used. It has the additional advantage of backwards compatability with some clients. Unfortunately, clients before Kerberos V5, Beta5, generate invalid checksums; if these clients are used, the -i option must be used.
Ignore authenticator checksums if provided. This option
ignore authenticator checksusm presented by current Kerberos clients
to protect initial connection information; it is the opposite of
-c. This option is provided because some older
clients -- particularly clients predating the release of Kerberos V5
Beta5 (May 1995) -- present bogus checksums that prevent Kerberos
authentication from succeeding in the default mode.
The parent of the login process manipulates the master side of the
pseduo terminal, operating as an intermediary between the login
process and the client instance of the
rlogin(1) program. In normal operation, the packet protocol described in
is invoked to provide ^S/^Q type facilities and propagate interrupt
signals to the remote programs. The login process propagates the
client terminals baud rate and terminal type, as found in the
environment variable, TERM; see
The screen or
window size of the terminal is requested from the client, and window
size changes from the client are propagated to the pseudo terminal.
Klogind supports the following options to control the form of the hostname
passed to login(1):
Controls the form of the remote hostname passed to login(1).
Specifying ip results in the numeric IP address always being
passed to login(1). Specifying a number, maxhostlen, sets the
maximum length of the hostname passed to login(1) before it will be
passed as a numeric IP address. If maxhostlen is 0, then the
system default, as determined by the utmp or utmpx structures, is
used. The nostriplocal and striplocal options, which must
be preceded by a comma, control whether or not the local host domain
is stripped from the remote hostname. By default, the equivalent of
striplocal is in effect.
Klogind supports five options which are used for testing
Set the keytab file to use.
Set the Kerberos realm to use.
Specify pathname to an alternative login program. Default: /usr/bin/login.
KRB5_HOME/sbin/login.krb5 may be specified.
Run in standalone mode, listening on port. The daemon will exit
after one connection and will not background itself.
Allows for standalone daemon operation. A new child is started for
each incoming connection and waits for it to finish before accepting
the next connection. This automagically figures out which port to bind
to if no port is specified.
All diagnostic messages are returned on the connection associated with the stderr, after which any network connections are closed. An error is indicated by a leading byte with a value of 1.
A fork by the server failed.
The users login shell could not be started.
A more extensible protocol should be used.