EN JA
RLOGIND(8)
RLOGIND(8) FreeBSD System Manager's Manual RLOGIND(8)

名称

rlogindリモートログインのサーバ

書式

rlogind [ -Daln]

解説

rlogind ユーティリティは、 rlogin(1) のためのサーバです。サーバは信頼できるホストからの特権ポート番号に基づいた認証を用いて、リモートログイン機能を提供します。

rlogind では、以下のオプションが使用可能です。

-D
TCP_NODELAY ソケットオプションを設定します。これは、いくつかのネットワークトラフィックの増大に対して、応答性を向上します。
-a
検証のために、ホスト名を問い合わせます。
-l
ユーザがスーパユーザとしてログインしない限り、一般ユーザの“ .rhosts”による、あらゆる認証を禁止します。
-n
キープアライブメッセージを禁止します。

rlogind ユーティリティは、“login”サービスの仕様に基づく番号のポートで、要求を受け付けます。詳しくは services(5) を参照してください。サービスの要求を受け取ると、以下のプロトコルを開始します。

  1. サーバはクライアントの要求元ポート番号を調べます。もしポート番号が512〜1023の範囲外であれば、サーバは接続を切断します。
  2. サーバはクライアントの要求元アドレスを調べ、それに対応するホスト名を求めます ( gethostbyaddr(3), hosts(5), named(8) を参照してください)。ホスト名を決定できなければ、ドット表記法によるホストアドレスを用います。ホスト名がサーバと同じドメインに属しているか (ドメイン名の最後の二つの構成要素に基づいて判断します)、あるいは -a オプションが指定されていたら、ホスト名に対するアドレスを調べて、ホスト名とアドレスが一致しているかどうかを検証します。アドレスの検証に失敗した場合は、通常の認証作業は行いません。

要求元ポートの番号を調べ終えたら、 rlogind は、 rshd(8) で説明している認証作業を開始します。そして、疑似端末 ( pty(4) を参照のこと) を割り当てると共に、ファイル記述子を操作して、この疑似端末のスレーブ側がログインプロセスの stdin, stdout, stderr になるようにします。認証作業が成功した場合には、 login(1) プログラムに -f オプションを指定してログインプロセスを生成します。自動認証作業に失敗した場合には、通常の端末回線からのログインの場合と同様に、ユーザに問い合わせをします。

ログインプロセスの親プロセスは、疑似端末のマスタ側を操作します。すなわちログインプロセスと、クライアント側の rlogin(1) プログラムを実体化したものとの間で処理を行います。通常の処理においては、‘ ^S/^Q’のような機能を提供したり、割り込み信号をリモートプログラムへと伝えるために pty(4) で説明しているパケットプロトコルを起動します。ログインプロセスは、クライアントの端末の通信速度や環境変数 TERM で指定されている端末タイプを伝えます。 environ(7) を参照してください。クライアント側に端末の画面、あるいはウィンドウの大きさを問い合わせます。また、クライアント側からウィンドウサイズの変更が疑似端末へ伝えられます。

トランスポートレベルのキープアライブメッセージは、オプション -n が指定されていない限り出力されます。キープアライブメッセージを利用すると、クライアントがクラッシュしたり、通信不能になってしまった時に、セッションをタイムアウトで終了することが可能になります。

関連ファイル

/etc/hosts
/etc/hosts.equiv
$HOME /.rhosts
/var/run/nologin

診断

すべての診断メッセージは、ネットワーク接続が切断された後に、最初に 1 の値のバイトが付加されて通知されます。 login(1) が起動された後にエラーが発生しない場合、処理成功の通知のために、NULL バイトを返します。
Try again.
サーバが fork(2) に失敗したことを表します。

歴史

rlogind コマンドは、 4.2BSD で登場しました。

IPv6 サポートは、WIDE/KAME プロジェクトによって追加されました。

バグ

このコマンドが用いている認証手続きは、それぞれのクライアントマシンと接続媒体が完全であるということを仮定したものです。これはセキュリティホールになりやすいのですが、“オープン”な環境においては有用な方針です。

全てのデータについて暗号化を行なう機能が実装されるべきです。

もっと発展性のあるプロトコルが用いられるべきです。

February 9, 2005 FreeBSD