rlogin [-8EKLdx] [-e char] [-k realm] [-l username] host
rlogin starts a terminal session on a remote host host.
rlogin first attempts to use the Kerberos authorization mechanism, described in the following subsection. If the remote host does not support Kerberos, the standard Berkeley authorization mechanism is used. The options are as follows:
|-8||The -8 option allows an eight-bit input data path at all times; otherwise, parity bits are stripped except when the remote side’s stop and start characters are other than ˆS/ˆQ.|
|-E||The -E option stops any character from being recognized as an escape character. When used with the -8 option, this provides a completely transparent connection.|
|-K||The -K option turns off all Kerberos authentication.|
|-L||The -L option allows the rlogin session to be run in litout mode.(See tty(4) for details).|
|-d||The -d option turns on socket debugging (see the setsockopt(2) man page) on the TCP sockets used for communication with the remote host.|
|-e||The -e option allows user specification of the escape character, which is the tilde (˜) by default. This specification may be as a literal character, or as an octal value in the form nnnn.|
|-k||The -k option requests rlogin to obtain tickets for the remote host in realm realm instead of the remote host’s realm as determined by krb_realmofhost(3).|
|-x||The -x option turns on DES encryption for all data passed via the rlogin session. This may impact response time and CPU utilization, but provides increased security.|
A line of the form <escape char> disconnects from the remote host. Similarly, the line <escape char>ˆZ will suspend the rlogin session, and <escape char><delayed-suspend char> suspends the send portion of the rlogin, but allows output from the remote system. By default, the tilde (˜) character is the escape character, and normally control -Y (ˆY) is the delayed-suspend character.
All echoing takes place at the remote site, so that (except for delays) the rlogin is transparent. Flow control via ˆS/ˆQ and flushing of input and output on interrupts is handled properly.
Each user may have a private authorization list in the file in his or her home directory. Each line in this file should contain a Kerberos principal name of the form principal.instance (@realm). If the originating user is authenticated to one of the principals named, access is granted to the account. The principal accountname.(@localrealm) is granted access if there is no file. Otherwise, a login and password will be prompted for on the remote machine as in login(1). To avoid certain security problems, the file must be owned by the remote user.
If Kerberos authentication fails, a warning message is printed and the standard Berkeley rlogin is used instead.