in.rlogind, rlogind - remote login server
/usr/sbin/in.rlogind [-s tos]
in.rlogind is the server for the rlogin(1) program. The server provides a remote login facility with authentication based on privileged port numbers.
in.rlogind is invoked by inetd(8) when a remote login connection is established. The rlogin protocol authentication procedure is as follows:
The server checks the client's source port. If the port is not in the range 512-1023, the server aborts the connection.
The server checks the client's source address. If an entry for the client exists in both /etc/hosts and /etc/hosts.equiv, a user logging in from the client is not prompted for a password. If the address is associated with a host for which no corresponding entry exists in /etc/hosts, the user is prompted for a password, regardless of whether or not an entry for the client is present in /etc/hosts.equiv. For more information, see the hosts(5) and hosts.equiv(5) man pages.
Once the source port and address have been checked, in.rlogind allocates a pseudo-terminal and manipulates file descriptors so that the slave half of the pseudo-terminal becomes the stdin, stdout, and stderr for a login process. The login process is an instance of the login(1) program, invoked with the –r.
The login process then proceeds with the pam(3PAM) authentication process. See SECURITY below. If automatic authentication fails, it reprompts the user to login.
The parent of the login process manipulates the master side of the pseudo-terminal, operating as an intermediary between the login process and the client instance of the rlogin program. In normal operation, a packet protocol is invoked to provide Ctrl-S and Ctrl-Q type facilities and propagate interrupt signals to the remote programs. The login process propagates the client terminal's baud rate and terminal type, as found in the environment variable, TERM.
The following option is supported:
Sets the IP TOS option.
rlogind and in.rlogind are IPv6–enabled. See ip6(4P).
in.rlogind uses pam(3PAM) for authentication, account management, and session management. The PAM configuration policy, configured in /etc/pam.conf or per-service files in /etc/pam.d/, specifies the modules to be used for in.rlogind. Here is a partial pam.conf file with entries for the rlogin command using the rhosts and UNIX authentication modules, and the UNIX account, session management, and password management modules.
The equivalent PAM configuration using /etc/pam.d/ would be the following entries in /etc/pam.d/rlogin:
auth sufficient pam_rhosts_auth.so.1 auth requisite pam_authtok_get.so.1 auth required pam_unix_auth.so.1 account required pam_unix_roles.so.1 account required pam_unix_projects.so.1 account required pam_unix_account.so.1 session required pam_unix_session.so.1
With this configuration, the server checks the client's source address. If an entry for the client exists in both /etc/hosts and /etc/hosts.equiv, a user logging in from the client is not prompted for a password. If the address is associated with a host for which no corresponding entry exists in /etc/hosts, the user is prompted for a password, regardless of whether or not an entry for the client is present in /etc/hosts.equiv. For more information, see the hosts(5) and hosts.equiv(5) man pages.
If there are no entries for the rlogin service, then the entries for the “other” service will be used. If multiple authentication modules are listed, then the user may be prompted for multiple passwords. Removing the pam_rhosts_auth.so.1 entry will disable the /etc/hosts.equiv and ~/.rhosts authentication protocol and the user would always be forced to type the password. The sufficient flag indicates that authentication through the pam_rhosts_auth.so.1 module is sufficient to authenticate the user. Only if this authentication fails is the next authentication module used.
See the attributes(7) man page for descriptions of the following attributes:
login(1), rlogin(1), ssh(1), svcs(1), pam(3PAM), hosts(5), hosts.equiv(5), pam.conf(5), attributes(7), environ(7), pam_authtok_check(7), pam_authtok_get(7), pam_authtok_store(7), pam_dhkeys(7), pam_passwd_auth(7), pam_unix_account(7), pam_unix_auth(7), pam_unix_session(7), smf(7), in.rshd(8), inetadm(8), inetd(8), sshd(8), svcadm(8)
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.
No entry in the host name database existed for the client's machine.
A fork by the server failed.
The user's login shell could not be started.
The authentication procedure used here assumes the integrity of each client machine and the connecting medium. This is insecure, but can be convenient in environments where it does not conflict with the local security policy.
All data exchanges over this protocol are performed without encryption, and have no protection against spoofing or snooping of traffic. The in.rlogind server is disabled by default on Oracle Solaris and most other modern operating systems, and may be removed in future versions of Oracle Solaris. Use of the sshd(8) server is strongly recommended instead.
The in.rlogind service is managed by the service management facility, smf(7), under the service identifier:
Administrative actions on this service, such as enabling, disabling, or requesting restart, can be performed using svcadm(8). Responsibility for initiating and restarting this service is delegated to inetd(8). Use inetadm(8) to make configuration changes and to view configuration information for this service. The service's status can be queried using the svcs(1) command.
This technology may be removed in a future release of Oracle Solaris.
The in.rlogind service has been present since the initial release of Solaris.
Support for IPv6 was added in Solaris 8.
Support for Kerberos was added in Solaris 10 3/05 and removed in Oracle Solaris 11.4.0. Prior to Solaris 10, a kerberized version was available in the Sun Enterprise Authentication Mechanism (SEAM) add-on package for Solaris.
The in.rlogind service was enabled by default in releases up through Solaris 9. In the Solaris 10 through 11.3 releases, the service was enabled under the generic_open.xml service profile, but disabled under the generic_limited_net.xml service profile. In Oracle Solaris 11.4, it is disabled by default.