RFC1282 日本語訳

Network Working Group                                          B. Kantor
Request for Comments: 1282                      Univ. of Calif San Diego
Obsoletes: RFC 1258                                        December 1991

コメントを求めるワーキンググループB.カンター要求をネットワークでつないでください: 1282年のCalifサンディエゴの大学は以下を時代遅れにします。 RFC1258 1991年12月

                               BSD Rlogin

BSD Rlogin

Status of this Memo

このMemoの状態

   This memo documents an existing protocol and common implementation
   that is extensively used on the Internet.  This memo provides
   information for the Internet community.  It does not specify an
   Internet standard.  Distribution of this memo is unlimited.

このメモは既存のプロトコルとインターネットで手広く使用される一般的な実装を記録します。 このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Protocol Description

プロトコル記述

   The rlogin facility provides a remote-echoed, locally flow-controlled
   virtual terminal with proper flushing of output [1].  It is widely
   used between Unix hosts because it provides transport of more of the
   Unix terminal environment semantics than does the Telnet protocol,
   and because on many Unix hosts it can be configured not to require
   user entry of passwords when connections originate from trusted
   hosts.

rlogin施設はリモートに反響していて、局所的に流れで制御された仮想端末を出力[1]を適切な洗い流すのに提供します。 TelnetプロトコルUnixの端末の環境意味論の以上の輸送を提供して、パスワードのユーザエントリーを必要としないのが多くのUnixホストの上で構成できるので、接続が信じられたホストから発するとき、それはUnixホストの間で広く使用されます。

   The rlogin protocol requires the use of the TCP.  The contact port is
   513.  An eight-bit transparent stream is assumed.

rloginプロトコルはTCPの使用を必要とします。 接触ポートは513です。 8ビットの透明なストリームは想定されます。

Connection Establishment

コネクション確立

   Upon connection establishment, the client sends four null-terminated
   strings to the server.  The first is an empty string (i.e., it
   consists solely of a single zero byte), followed by three non-null
   strings: the client username, the server username, and the terminal
   type and speed.  More explicitly:

コネクション確立のときに、クライアントは4個のヌルで終えられたストリングをサーバに送ります。1番目が空のストリングである、(唯一シングルから成る、バイトがありません) 3個の非ヌルストリングが支えます: クライアントユーザ名、サーバユーザ名、および端末は、タイプして、疾走します。 より明らか:

        <null>
        client-user-name<null>
        server-user-name<null>
        terminal-type/speed<null>

<のヌル>クライアントユーザ名の<のヌル>サーバユーザ名の<のヌル>端末のタイプ/速度の<のヌル>。

        For example:

例えば:

        <null>
        bostic<null>
        kbostic<null>
        vt100/9600<null>

ヌルbosticヌルkbostic<のヌル>vt100/9600<ヌル><><>。

   The server returns a zero byte to indicate that it has received these

サーバは、これらを受けたのを示すためにバイトを全くaに返しません。

Kantor                                                          [Page 1]

RFC 1282                       BSD Rlogin                  December 1991

カンター[1ページ]RFC1282BSD Rlogin1991年12月

   strings and is now in data transfer mode.  Window size negotiation
   may follow this initial exchange (see below).

ストリング、データ転送モードによる現在はそうです。 ウィンドウサイズ交渉はこの初期の交換に続くかもしれません(以下を見てください)。

From Client to Server (and Flow Control)

クライアントからサーバまで(そして、フロー制御)

   Initially, the client begins operation in "cooked" (as opposed to
   to "raw") mode.  In this mode, the START and STOP (usually ASCII
   DC1,DC3) characters are intercepted and interpreted by the client to
   start and stop output from the remote server to the local terminal,
   whereas all other characters are transmitted to the remote host as
   they are received.  (But see below for the handling of the
   local-escape character.)

と対照的に、初めはクライアントが「煮えた」状態で操業を開始する、(「生」) モードに。 このモードで、STARTとSTOP(通常ASCII DC1、DC3)キャラクタは、リモートサーバからローカル・ターミナルに始まって、出力を止めるためにクライアントによって途中で捕らえられて、解釈されますが、彼らが受け取られているとき、他のすべてのキャラクタがリモートホストに伝えられます。 (しかし、ローカルの拡張文字の取り扱いに関して以下を見てください。)

   In "raw" mode, the START and STOP characters are not processed
   locally, but are sent as any other character to the remote server.
   The server thus determines the semantics of the START and STOP
   characters when in "raw" mode; they may be used for flow control or
   have quite different meanings independent of their ordinary usage on
   the client.

「生」のモードで、STARTとSTOPキャラクタを局所的に処理しませんが、いかなる他のキャラクタとしてもリモートサーバに送ります。「生」のモードでその結果、サーバはSTARTとSTOPキャラクタの意味論を決定します。 彼らには、クライアントの上のそれらの普通の用法の如何にかかわらず、フロー制御に使用されるか、または全く異なった意味があるかもしれません。

Screen/Window Size

スクリーン/ウィンドウサイズ

   The remote server indicates to the client that it can accept window
   size change information by requesting a window size message (as out
   of band data) just after connection establishment and user
   identification exchange.  The client should reply to this request
   with the current window size.

リモートサーバは、コネクション確立とユーザ登録名交換のすぐ後にウィンドウサイズメッセージ(バンドデータのように)を要求することによってウィンドウサイズ変化情報を受け入れることができるのをクライアントに示します。 クライアントは現在のウィンドウサイズでこの要求に答えるべきです。

   If the remote server has indicated that it can accept client window
   size changes and the size of the client's window or screen dimensions
   changes, a 12-byte special sequence is sent to the remote server to
   indicate the current dimensions of the client's window, should the
   user process running on the server care to make use of that
   information.

リモートサーバが、クライアントの窓かスクリーン寸法変化のクライアントウィンドウサイズ変化とサイズを受け入れることができるのを示したなら、クライアントの窓の現在の広さを示すために12バイトの特別な系列をリモートサーバに送ります、ユーザがその情報を利用するためにサーバ注意で動きながら処理するなら。

   The window change control sequence is 12 bytes in length, consisting
   of a magic cookie (two consecutive bytes of hex FF), followed by two
   bytes containing lower-case ASCII "s", then 8 bytes containing the
   16-bit values for the number of character rows, the number of
   characters per row, the number of pixels in the X direction, and the
   number of pixels in the Y direction, in network byte order.  Thus:

長さは窓の変化制御配列が12バイトです、次に、小文字のASCII「s」を含む2バイト、キャラクタ行の数、1行あたりのキャラクタの数、X方向へのピクセル数、およびY方向へのピクセル数のための16ビットの値を含む8バイトがあとに続いた魔法のクッキー(連続した2バイトの十六進法FF)から成って、ネットワークバイトオーダーで。 このようにして:

        FF FF s s rr cc xp yp

FF FF s s rr cc xp yp

   Other flags than "ss" may be used in future for other in-band control
   messages.  None are currently defined.

"ss"以外の旗はこれから、バンドにおける他のコントロールメッセージに使用されるかもしれません。 なにも現在、定義されません。

Kantor                                                          [Page 2]

RFC 1282                       BSD Rlogin                  December 1991

カンター[2ページ]RFC1282BSD Rlogin1991年12月

From Server to Client

サーバからクライアントまで

   Data from the remote server is sent to the client as a stream of
   characters.  Normal data is simply sent to the client's display, but
   may be processed before actual display (tabs expanded, etc.).

キャラクタの流れとしてリモートサーバからのデータをクライアントに送ります。 正常なデータを単にクライアントのディスプレイに送りますが、実際のディスプレイ(広げられたタブなど)の前に処理するかもしれません。

   The server can imbed single-byte control messages in the data stream
   by inserting the control byte in the stream of data and pointing the
   TCP "urgent-data" pointer at the control byte.  When a TCP urgent-
   data pointer is received by the client, data in the TCP stream up to
   the urgent byte is buffered for possible display after the control
   byte is handled, and the control byte pointed to is received and
   interpreted as follows:

サーバは、データ・ストリームでコントロールバイトをデータのストリームに挿入して、コントロールバイトでTCP「緊急のデータ」指針を指すことによって、単一のバイトコントロールメッセージを埋め込むことができます。 TCPの緊急のデータ指針がクライアントによって受け取られるとき、コントロールバイトが扱われた後に緊急のバイトまでのTCPストリームにおけるデータが可能なディスプレイのためにバッファリングされて、示されたコントロールバイトは、以下の通り受け取られて、解釈されます:

02   A control byte of hex 02 causes the client to discard all buffered
     data received from the server that has not yet been written to the
     client user's screen.

02 十六進法02のコントロールバイトで、クライアントはまだ書かれていないサーバからクライアントユーザのスクリーンまで受け取られたすべてのバッファリングされたデータを捨てます。

10   A control byte of hex 10 commands the client to switch to "raw"
     mode, where the START and STOP characters are no longer handled by
     the client, but are instead treated as plain data.

10 十六進法10のコントロールバイトは、クライアントが「生」のモードに切り替わると命令します。(そこでは、STARTとSTOPキャラクタは、もうクライアントによって扱われませんが、代わりに明瞭なデータとして扱われます)。

20   A control byte of hex 20 commands the client to resume interception
     and local processing of START and STOP flow control characters.

20 十六進法20のコントロールバイトは、クライアントがSTARTとSTOPフロー制御キャラクタの妨害とローカル処理を再開すると命令します。

80   The client responds by sending the current window size as above.

80 クライアントは、同じくらい上で現在のウィンドウサイズを送ることによって、応じます。

   All other values of the urgent-data control byte are ignored.  In all
   cases, the byte pointed to by the urgent data pointer is NOT written
   to the client user's display.

緊急のデータコントロールバイトの他のすべての値が無視されます。 すべての場合では、緊急のデータ指針によって示されたバイトはクライアントユーザのディスプレイに書かれていません。

Connection Closure

接続閉鎖

   When the TCP connection closes in either direction, the client or
   server process which notices the close should perform an orderly
   shut-down, restoring terminal modes and notifying the user or
   processes of the close before it closes the connection in the other
   direction.

どちらかの方向、クライアントまたはサーバにおけるTCP接続閉鎖がどの通知を処理するかとき、閉鎖は規則的な閉鎖を実行するべきです、ターミナルモードを回復して、もう片方の方向に接続を終える前に閉鎖のユーザかプロセスに通知して。

Implementation Notes

実装注意

   The client defines a client-escape character (customarily the tilde,
   "~"), which is handled specially only if it is the first character to
   be typed at the beginning of a line.  (The beginning of a line is
   defined to be the first character typed by the client user after a
   new-line [CR or LF] character, after a line-cancel character, after
   resumption of a suspended client session, or after initiation of the
   connection.)

クライアントがクライアント拡張文字を定義する、(通例、ティルド、「~」)、特に、それが系列の始めにタイプされるべき最初のキャラクタである場合にだけ扱われる。 (系列の始まりは復帰改行[CRかLF]キャラクタの後にクライアントユーザによってタイプされた最初の文字になるように定義されます、吊したクライアントセッションの再開の後、または接続の開始の後の系列取消文字の後に。)

Kantor                                                          [Page 3]

RFC 1282                       BSD Rlogin                  December 1991

カンター[3ページ]RFC1282BSD Rlogin1991年12月

   The client-escape character is not transmitted to the server until
   the character after it has been examined, and if that character is
   one of the defined client escape sequences, neither the client-escape
   nor the character following it are sent.  Otherwise, both the
   client-escape character and the character following it are sent to
   the server as ordinary user input.

それの後のキャラクタが調べられるまで、クライアント拡張文字をサーバに伝えません、そして、そのキャラクタが定義されたクライアントエスケープシーケンスの1つであるなら、クライアントエスケープもそれの後をつけないキャラクタも送ります。 さもなければ、一般ユーザ入力としてクライアント拡張文字とそれの後をつけるキャラクタの両方をサーバに送ります。

   If the character following the client-escape character is the dot
   ".", or the client-defined end-of-file character (usually control-D),
   the connection is closed.  This is normally treated by the server as
   a disconnection, rather than an orderly logout.

「クライアント拡張文字に従うキャラクタがドットであるなら」。」 クライアントによって定義されたファイルの終りキャラクタ(通常コントロールD)、接続は閉じられます。 看護兵よりむしろ断線がログアウトするとき、通常、これはサーバによって扱われます。

   Other characters (client-defined, usually control-Z and control-Y)
   are used to temporarily suspend the rlogin client when the host has
   that ability.  One character suspends both remote input and output;
   the other suspends remote input but allows remote output to continue
   to be directed to the local client's terminal.

他のキャラクタ(クライアントによって定義されて、通常、Zを制御していてYを制御している)は、ホストにその能力があるとき、一時rloginクライアントを停学処分にするのに使用されます。 1つのキャラクタがリモート入力と出力の両方を吊します。 もう片方で、リモート入力を中断させますが、地元のクライアントの端末に向けられリモート出力を続けています。

   Most client implementations have invocation switches that can defeat
   normal output processing on the client system, and which can force
   the client to remain in raw mode despite switching notification from
   the server.

ほとんどのクライアント実装がクライアントシステムの上で基準出力処理を破ることができて、切り換え通知にもかかわらず、クライアントがサーバから生のモードでやむを得ず残ることができる実施のスイッチを持っています。

A Cautionary Tale [2]

訓戒的な物語[2]

   The rlogin protocol (as commonly implemented) allows a user to set up
   a class of trusted users and/or hosts which will be allowed to log on
   as himself without the entry of a password.  While extremely
   convenient, this represents a weakening of security that has been
   successfully exploited in previous attacks on the internet.  If one
   wishes to use the password-bypass facilities of the rlogin service,
   it is essential to realize the compromises that may be possible
   thereby.

rloginプロトコル(一般的に実装されるとしての)で、ユーザは自分としてパスワードのエントリーなしでログオンできる信じられたユーザ、そして/または、ホストのクラスを設立できます。 非常に便利ですが、これはインターネットに対する前の攻撃で首尾よく利用されたセキュリティの弱化を表します。 人がrloginサービスのパスワード迂回施設を使用したいと思うなら、その結果可能であるかもしれない感染がわかるのは不可欠です。

   Bypassing password authentication from trusted hosts opens ALL the
   systems so configured when just one is compromised.  Just as using
   the same password for all systems to which you have access lets a
   villain in everywhere you have access, allowing passwordless login
   among all your systems gives a marauder a wide playing field once he
   has entered any of your systems.  One compromise that many feel
   achieves a workable balance between convenience and security is to
   allow password bypass from only ONE workstation to the other systems
   you use, and NOT allow it between those systems.  With this measure,
   you may have reduced exposure to a workable minimum.

信じられたホストからパスワード認証を迂回させると、したがってちょうど1つが感染されるときシステムが構成したすべてが開きます。 ちょうどあなたがアクセスを持っているすべてのシステムに同じパスワードを使用すると悪人があなたがアクセスを持っているいたる所で入れられるとき、あなたのすべてのシステムの中でパスワードなしログインを許すと、彼がいったんあなたのシステムのどれかを入れると、広い運動場は略奪に与えられます; 獲得する多くが便利とセキュリティの間の実行可能なバランスを感じる1つの感染は、ONEワークステーションだけからあなたが使用する他のシステムまでパスワード迂回を許して、それらのシステムの間にそれは許容しないことです。この測定に従って、あなたは、暴露を実行可能な最小限まで減少させたかもしれません。

   The trusted host specification is ordinarily one of a host name.  It
   is possible, by compromise of your organization's domain name server,
   or compromise of your network itself, for a villain to make an

信じられたホスト仕様は通常、aのひとりが名前をホスティングするということです。 それは可能です、あなたの組織のドメイン名サーバの感染、またはあなたのネットワーク自体の感染で、作る悪人のために

Kantor                                                          [Page 4]

RFC 1282                       BSD Rlogin                  December 1991

カンター[4ページ]RFC1282BSD Rlogin1991年12月

   untrusted host masquerade as a trusted system.  There is little that
   a user can do about this form of attack.  Luckily, so far such
   attacks have been rare, and often cause enough disruption of a
   network that attempts are quickly noticed.

信じられたシステムとしての信頼されていないホスト仮面舞踏会。 少ししかがユーザがこの形式の攻撃に関してできるありません。 運よいのと、今までのところ、そのような攻撃は、まれであり、しばしば気付かれた状態で試みがすぐにそうであるネットワークの十分な分裂を引き起こします。

   When the file containing a user's list of trusted logins is
   inadvertently left writeable by other users, untrustworthy additions
   may be made to it.

他のユーザがうっかりユーザの信じられたログインのリストを含むファイルを「書-可能」に残すとき、信頼できない追加をそれにするかもしれません。

   Secure authentication extensions to the rlogin protocol (Kerberos,
   et al) can greatly reduce the possibility of compromise whilst still
   allowing the convenience of bypassing password entry.  As these
   become more widely deployed in the internet community, the hazards
   of rlogin will decrease.

まだパスワードエントリーを迂回させる便利を許容している間、rloginプロトコル(ケルベロス、他)への安全な認証拡大は感染の可能性を大いに減少させることができます。 これらがインターネット共同体では、広くより配布されるようになるのに従って、rloginの危険は減少するでしょう。

References

参照

      [1] Stevens, W., "UNIX Network Programming", ISBN 0-13-949876-1.

[1] スティーブンス、W.、「UNIXネットワーク・プログラミング」、ISBN0-13-949876-1。

      [2] Garfinkel & Spafford, "Practical Unix Security",
          ISBN 0-937175-72-2.

[2]ガーフィンケルとSpafford、「実用的なunixセキュリティ」、ISBN0-937175-72-2。

Security Considerations

セキュリティ問題

   See the "A Cautionary Tale" section above.

「A訓戒的な物語」セクションが上であることを見てください。

Author's Address

作者のアドレス

   Brian Kantor
   University of California at San Diego
   Network Operations C-024
   La Jolla, CA 92093-0214

ブライアン・カンターカリフォルニア大学サンディエゴ校ネットワークオペレーションC-024ラ・ホーヤ、カリフォルニア92093-0214

   Phone: (619) 534-6865

以下に電話をしてください。 (619) 534-6865

   EMail: brian@UCSD.EDU

メール: brian@UCSD.EDU

Kantor                                                          [Page 5]

カンター[5ページ]