Telnet
遠隔の機器と端末の間で文字や制御情報をやり取りし、対話的な操作を行うためのアプリケーション層のプロトコルである。通常はTCPの23番ポートへ接続する。基本仕様には通信内容の暗号化がない。
イマシルちゃんの解説
Telnetは、手元の端末から離れたサーバやルータへ文字を送り、返ってきた結果を見ながら操作するための通信ルールだよ。
端末ごとに文字の扱いが違っても、共通の形式へそろえてやり取りできるんだ。
接続するとログイン画面やコマンドの入力欄が表示されることがあるよ。
ただし基本のTelnetでは、入力したパスワードや操作の内容が読み取れる形で回線を流れてしまうの。
画面でパスワードが見えなくても、通信の中身が守られているわけではないんだ。
そのため遠隔管理では、相手の確認と通信の保護を備えたSSHなどを使うことが大切だよ。
この解説はわかりやすかったですか?
より深い解説
遠隔の端末として操作する
Telnetは文字による対話を遠隔で行うためのプロトコルである。端末から送った文字をサーバ側の処理へ渡し、その結果を端末へ返す。遠隔ログインが代表的な用途だが、端末と処理系を接続する通信の規則であり、ログイン画面の文言や操作できるコマンドまで一律に定めているわけではない。
通信にはTCPを使う。クライアントからサーバの待受ポートへ接続し、一本の双方向の通信路で入力、出力、Telnetの制御情報を運ぶ。FTPのように操作用と転送用で別々のTCP接続を作る構造ではない。標準的なサーバ側のポートはIANAの登録で確認できる。クライアント側の送信元ポートまで同じ番号に固定する必要はない。
一般的な接続では、TCP接続の確立後に端末の扱いなどを交渉し、サーバ側のログイン処理やコマンド処理と対話する。利用者がログインできるかどうかはサーバ側の認証や設定にも依存する。接続できたことと利用者の認証に成功したことは別の段階である。基本の通信モデルはRFC 854に定められている。
端末の違いを共通の形式へそろえる
機器ごとに文字コードや改行の扱いが異なると、受け取った文字をそのまま表示しても意図した動作にならない。TelnetではNVT(Network Virtual Terminal:ネットワーク仮想端末)という共通の端末モデルを使い、双方が自分の端末の表現と通信上の表現を変換する。実物の端末をネットワーク内に置くという意味ではない。
既定の文字表現は7ビットのUS-ASCIIを最上位ビットが0の8ビット単位で運ぶ形式である。端末の種類や文字の扱いを拡張する場合は、双方で追加機能を使うことに合意する。TCPが8ビットのデータを運べるからといって、Telnetの既定の表示規則が任意の文字列に対応するわけではない。
既定の端末モデルにおける表示上の改行と行頭復帰は、次のように表す。CRは行頭復帰、LFは次の行へ進める制御文字である。
| 表示上の動作 | 通信上の並び | 意味 |
|---|---|---|
| 次の行の先頭へ移る | CR LF | 行頭復帰と改行を組み合わせる |
| 行を進めずに先頭へ戻る | CR NUL | 復帰だけを行う。後ろのゼロ値は表示する文字ではない |
ただし、遠隔端末からASCIIのサーバへ入力する場面では、上の二つの並びをどちらも行末キーと同じ効果として扱うことが求められる。表示の動作と入力の解釈を混同しないことが必要である。また、バイナリ伝送を合意した方向では通常の改行変換を行わない。これらの補足はRFC 1123の3.2.7節・3.3.1節で説明されている。
文字のデータと制御を区別する
Telnetは文字だけをそのまま転送する仕組みではない。通信の途中に制御コマンドを入れるときは、IAC(Interpret As Command)という識別用のバイトを置く。値は十進数で255、十六進数で0xFFであり、続くバイトを制御コマンドとして解釈させる。
同じ値を通常のデータとして送る場合は、そのバイトを2回続けて送って区別する。この扱いはバイナリ伝送を合意した後も必要である。そのためTelnetクライアントを、任意のバイト列を一切変更せずに通す道具と考えてはならない。RFC 1123の3.2.7節は、バイナリ伝送時にも制御の解釈を維持することを規定している。
端末の表示や入力の扱いなどを変える追加機能をオプションという。交渉では識別用バイト、交渉コマンド、オプション番号を順に送る。基本となる四つのコマンドは、送った側と受け取った側のどちらがその機能を実行するかで区別する。
| コマンド | 送った側から見た意味 |
|---|---|
WILL | 自分がその機能を実行する提案、または実行を受け入れる応答 |
WON'T | 自分はその機能を実行しない、または停止するという通知 |
DO | 相手にその機能の実行を求める要求、または相手の実行を受け入れる応答 |
DON'T | 相手にその機能の停止を求める要求、または相手の実行を受け入れない応答 |
例えばECHOは、受け取った入力文字を送り返す機能である。サーバがこの機能を実行すると提案し、クライアントが受け入れれば、クライアントは戻ってきた文字を表示できる。機能の実行方向は別々に交渉するため、一方向で有効になったからといって逆方向でも有効になったとは限らない。送り返しの動作はRFC 857に定められている。
未対応のオプションは拒否し、現在の状態に対する応答を新しい要求と取り違えて交渉を無限に繰り返さないようにする。端末の種類など追加の値が必要な機能では、利用の合意後にSBとSEの制御で囲んだ副交渉を行う。オプションの仕様と副交渉の枠組みはRFC 855、各番号はIANAのTelnet Optionsで確認できる。
認証画面があっても通信は保護されない
基本のTelnetでは、利用者名、パスワード、操作コマンド、実行結果が読み取れる形で通信される。パスワード入力中に画面へ文字を表示しないことは、端末の表示を抑えているだけである。通信経路上で盗み見られない性質である機密性や、通信内容の改変を検出する完全性を基本仕様だけでは保護できない。
サーバ側が利用者のパスワードを確認することと、クライアントが接続先を暗号技術によって認証することも別である。ログイン画面が出たからといって、それが本物の機器であると証明されたわけではない。
Telnetには認証や通信保護を追加する拡張もある。ただしクライアントの名前やポート番号だけで、その拡張が有効だと判断することはできない。RFC 4248の安全性に関する説明でも、拡張を使うには有効化と交渉結果の確認が必要だとされている。本記事の平文という説明は、そうした追加保護を使わない基本の通信を指す。
| 比較項目 | 基本のTelnet | SSH |
|---|---|---|
| 通常のサーバ側ポート | TCP 23 | TCP 22 |
| 操作データの保護 | 平文で送る | 暗号化と改ざん検知を行う |
| 接続先の確認 | 基本仕様に暗号学的なサーバ認証はない | サーバの鍵などを検証する |
| 利用者の確認 | サーバ側のログイン処理などが行う | 保護された通信路上で利用者を認証する |
SSHは安全な遠隔ログインのためのプロトコルとして、接続先の認証と通信の保護を組み合わせる。RFC 4251で構成が定められている。遠隔管理ではSSHなどへ移行し、Telnetが必要な旧機器は管理用ネットワークや接続元を限定する。VPNを経由する場合も、保護されるのはVPNの両端の間である。終端から機器までのTelnet区間の扱いも確認する。
クライアントで接続する例
ここではFreeBSDのtelnetクライアントを例にする。実行にはクライアントが導入されていること、接続先でサーバが待ち受けていること、経路とファイアウォールが接続を許可していることが必要である。実際の利用は管理者が許可した検証先や管理対象で行う。
telnet 192.0.2.25 23
このアドレスはRFC 5737の文書用アドレスを用いた例であり、そのまま接続できる試験サービスではない。実行するときは確認済みの対象アドレスへ置き換える。接続先の設定が標準と異なる場合はポート番号も合わせる。
接続中にクライアントを終了するには、通常の設定ではCtrl+]で手元のコマンドモードへ戻り、telnet>のプロンプトでquitを入力する。遠隔機器のコマンド入力欄にこの文字列を送る操作とは異なる。エスケープ文字は設定で変更できるため、画面に示される案内も確認する。引数と終了方法はFreeBSDのtelnetマニュアルに記載されている。
別のサービスへの接続確認で分かること
telnetコマンドには接続先のTCPポート番号を指定できるため、Telnet以外のサービスへの接続確認にも使われる。ただし、これはクライアントプログラムの利用方法であり、そのサービスがTelnetプロトコルに変わるわけではない。
Connectedなどと表示された時点で分かるのは、まず指定した宛先へのTCP接続が成立したことである。HTTPの正常応答、利用者の認証、必要なデータの取得まで確認できたことにはならない。接続後のアプリケーションの対話は別途確認する必要がある。
HTTPSの待受ポートに接続できても、通常のTelnetクライアントでTLSのハンドシェイクや証明書検証を完了できるわけではない。TLSを使うサービスは、それに対応したクライアントや実際のアプリケーションで調べる。UDPサービスの到達性もTCPの接続確認からは判断できない。
また、端末入力の改行変換や制御バイトの解釈が、相手の期待するデータと食い違う場合がある。どのポートを指定したかによってオプション交渉の開始動作が異なる実装もあるため、バイナリ形式のサービスなどを汎用のTelnet入力で検査できるとは限らない。
障害は接続と対話に分けて調べる
| 観測した状態 | 確認する箇所 |
|---|---|
| 接続要求がタイムアウトする | 宛先、経路、パケット破棄を行うフィルタ、応答側の経路 |
Connection refusedになる | 待受サービスの有無、ポート番号、明示的に拒否する機器や設定 |
| 接続したが表示が進まない | サーバ側の処理、オプション交渉、相手が入力を待つプロトコルかどうか |
| 文字が二重になる、改行が合わない | 文字を送り返す側、端末モード、改行の扱い |
| ログインで拒否される | 利用者名、認証情報、アカウントの状態、ログイン許可設定 |
拒否応答と無応答は手掛かりが異なるが、表示だけで機器の故障箇所を断定しない。サーバのログやパケットの記録と合わせて、通信のどの段階まで進んだかを確かめる。操作の成否と通信経路の保護も別々に評価する必要がある。