rsh [-n] [-a] [-K] [-PN | -PO] [-x] [-f | -F] [-l username]
[-k realm] hostname command
rsh hostname [-n] [-a] [-K] [-PN | -PO] [-x] [-f | -F]
[-l username] [-k realm] command
remsh [-n] [-a] [-K] [-PN | -PO] [-x] [-f | -F] [-l username]
[-k realm] hostname command
remsh hostname [-n] [-a] [-K] [-PN | -PO] [-x] [-f | -F]
[-l username] [-k realm] command
hostname [-n] [-a] [-PN | -PO] [-x] [-f | -F]
[-l username] [-k realm] command
rsh は、hostname が示すホストに接続し、command が示すコマンドを実行します。rsh は自身の標準入力のデータをリモートコマンドにコピーし、リモートコマンドの標準出力を自身の標準出力にコピーし、さらに、リモートコマンドの標準エラー出力を 自身の標準エラー出力にコピーします。割り込み、停止、および終了シグナルは、リモートコマンドに伝えられます。通常 rsh は、リモートコマンドが終了したときに終了します。
ユーザーは、Kerberos V5 認証を使用して、rsh セッションを安全にするかどうかを選択できます。また、転送されるデータも暗号化できます。rsh セッションで Kerberos 認証を使用するには、任意の Kerberos 固有オプションを使用します (–a、–PN または –PO、–x、–f または –F、および –k realm)。これらのオプションの一部 (–a、–x、–PN または –PO、および –f または –F) は、krb5.conf(4) の [appdefaults] セクションにも指定できます。これらのオプションの使用法と期待される動作については、次の「オプション」セクションを参照してください。Kerberos 承認を使用する場合、アカウントの承認は、krb5_auth_rules(5) の規則によって制御されます。Kerberos 承認が失敗した場合、–PO オプションをコマンド行に明示的に指定するか、krb5.conf(4) 経由で指定している場合にのみ、rhosts を使用する通常の rsh へのフォールバックが発生します。–PN または –PO、–x、–f または –F、および –k realm オプションは、–a オプションの上位集合であることに注意してください。
command を省略すると、rsh は単一のコマンドを実行する代わりに、rlogin(1) を使ってそのユーザーをリモートホストにログインします。
rsh は command の終了ステータスを返しません。
シェルのメタキャラクタのうち、引用符で囲まれていないものはローカルマシン上で解釈されます。引用符で囲まれているものは、リモートマシン上で解釈されます。「使用例」を参照してください。
特定のユーザーのログインシェルの初期化ファイル (.cshrc など) でロケールが設定されていない場合、rsh はコマンドを実行するときに、常に C ロケールを使用します。リモートマシンのデフォルトのロケールは使用しません。
このコマンド自身は暗号化されずにリモートシステムに送信されます。それ以降の転送はすべて暗号化されます。–x を参照してください。
サポートしているオプションは、次のとおりです。
このオプションは、Kerberos 認証を明示的に有効にし、アクセス制御において .k5login ファイルを信用します。サーバー側での in.rshd(1M) による承認チェックが成功し、.k5login ファイルがアクセス権を許可する場合、ユーザーは rsh コマンドを実行することが許可されます。
ローカルの証明書 (Kerberos チケット許可チケット) のコピーをリモートシステムに転送します。この証明書は再転送可能ではありません。このチケット許可チケットを転送する必要があるのは、リモートホスト上で Kerberos 認証を使用しているほかのネットワークサービスで自分自身を認証する必要がある場合です。たとえば、リモートホスト上にある自分のホームディレクトリが Kerberos V5 経由で NFS マウントされている場合などです。この場合、ローカルの証明書を転送しなければ、自分のホームディレクトリにアクセスできません。このオプションは、–F オプションと互いに排他の関係にあります。
ローカルの証明書 (Kerberos チケット許可チケット) のコピーをリモートシステムに転送します。この証明書は再転送可能です。–F オプションは、–f オプションが提供する機能の上位集合を提供します。たとえば、–f オプションの場合、リモートホストに接続した後に、/usr/bin/ftp、/usr/bin/telnet、/usr/bin/rlogin、または /usr/bin/rsh を –f オプションまたは –F オプションで呼び出そうとしても失敗します。つまり、単一のネットワーク署名をほかのシステムにプッシュできません。このオプションは、–f オプションとは相互排他的です。
rsh は、krb5.conf(4) で定義されているリモートホストの領域ではなく、指定した realm 内のリモートホスト用のチケットを取得します。
このオプションは、Kerberos 認証を明示的に無効にします。このオプションを使用すると、krb5.conf(4) の autologin 変数をオーバーライドできます。
リモートユーザー名として、ユーザー自身のローカルユーザー名の代わりに username を使用します。このオプションを省略すると、リモートユーザー名はローカルユーザー名と同じになります。
rsh の入力先を /dev/null に変更します。このオプションは、rsh とそれを呼び出したシェルとの間での、予期できない干渉を防ぐ上で便利です。たとえば、rsh を実行していて、さらにバックグラウンドで rsh を呼び出した場合、その入力先を端末以外に変更しないと、リモートコマンドの読み取りがない場合でも 処理が妨げられてしまいます。–n オプションを指定すれば、このような事態は避けられます。
Kerberos の「rcmd」プロトコルの新しいバージョン (–PN) または古いバージョン (–PO) を明示的に要求します。新しいプロトコルは、古いプロトコルで蔓延している多くのセキュリティの問題を回避し、より安全であると考えられますが、古い (MIT/SEAM) サービスとは相互運用できません。PO オプションで古いプロトコルを明示的に指定するか、krb5.conf(4) 経由で指定していないかぎり、デフォルトでは、新しいプロトコルが使用されます。古い「rcmd」プロトコルを使用しているときに Kerberos 承認が失敗した場合、Kerberos 承認を使用しない通常の rsh へのフォールバックが発生します。これは、新しい、より安全な「rcmd」プロトコルを使用している場合には当てはまりません。
ネットワークセッションのトラフィックを暗号化します。「機能説明」を参照してください。
リモートシェルの種類 ( sh や rsh など) は、リモートシステム上の /etc/passwd ファイル中のユーザーのエントリにより決められます。
次のオペランドを指定できます。
指定された hostname で実行するコマンド
ファイルが 2G バイト (231 バイト) 以上ある場合の rsh と remsh の動作については、largefile(5) を参照してください。
rsh および remsh コマンドは、IPv6 に対応しています。ip6(7P) を参照してください。現在のところ、IPv6 は Kerberos V5 認証ではサポートされません。
ホスト名は hosts データべース (/etc/hosts ファイルに含めることができる)、インターネットドメイン名データべース、あるいはその両方に書かれています。各ホストには 1 つの正式名 (データべースエントリの最初の名前) があり、さらにいくつかのニックネームが存在することもあります。hostname 引数には、正式なホスト名とニックネームの いずれかを指定します。
rsh を実行するファイル名が rsh でなければ、rsh はそのファイル名を hostname 引数として使用します。これによりユーザーは、ホスト名で rsh に対するシンボリックリンクを生成でき、実行時にそのホスト上のリモートシェルを呼び出せます。ディレクトリを作成し、それを共通に使われる ホスト名でシンボリックリンクにつなぎ、さらにそのディレクトリをユーザー自身の シェルの検索パスに含めることにより、シェルに hostname を入力するだけで rsh を実行することができます。
rsh を remsh で呼び出した場合、rsh は /usr/bin/remsh の存在を確認します。このファイルが存在 する場合、rsh は remsh を rsh の別名として処理します。/usr/bin/remsh が存在しない場合、rsh は remsh をホスト名として処理します。
Kerberos 承認を使用する rsh セッションの場合、各ユーザーは自分のホームディレクトリの .k5login ファイルに、専用の承認リストを持つことができます。このファイルの各行には、形式 principal/instance@realm の Kerberos 主体名が入っている必要があります。~/.k5login ファイルが存在する場合、起点ユーザーが ~/.k5login ファイルに指定された主体の 1 人であると認証された場合にのみ、起点ユーザーのアカウントにアクセス権が付与されます。それ以外の場合は、authenticated-principal-name → local-user-name マッピング規則を使用して、起点ユーザーの認証された主体名をローカルアカウント名にマッピングできる場合にのみ、起点ユーザーのアカウントにアクセス権が付与されます。.k5login ファイル (アクセス制御用) が処理されるのは、Kerberos 認証が行われるときだけです。
セキュリティー保護されていない rsh セッションの場合、各リモートマシンで /etc/hosts.equiv という名のファイルを使用できます。このファイルには、そのマシンとユーザー名を共有する、信頼できるホスト名のリストが含まれています。ローカルマシン上とリモートマシン上でのユーザー名が同一のユーザーは、リモートマシンの /etc/hosts.equiv ファイルにリストされているマシンから rsh を実行することができます。個々のユーザーは、このような同等名リストを個人用の .rhosts ファイルとして、自身のホームディレクトリに作成することができます。このファイル中の各行には 2 つの名前、 hostname と username が含まれ、両者はスペースで区切られます。username で示すユーザーが hostname で示すホストにログインしていれば、そのユーザーは rsh を使って、リモートユーザーとしてリモートマシンにアクセスできます。ローカルホスト名がリモートマシン上の /etc/hosts.equiv ファイル中に見つからず、ローカルのユーザー名とホスト名がリモートユーザーの .rhosts ファイル中に見つからない場合、アクセスは拒否されます。/etc/hosts.equiv または .rhosts ファイルに記録されているホスト名は、hosts データべースに登録されている正式なホスト名である必要があります。つまりこの両ファイル中には、ニックネームは指定できません。
ユーザーアカウントがロックされていると、rsh を使用して、ホスト名からのユーザーとして ログインすることはできません。
リモートマシン上でアクセスが拒否されたときは、command 引数が省略されていない限り、rsh はパスワードの入力を要求するプロンプトを出力しません。
次のコマンドは、リモートのマシン lizard 上にあるファイル lizard.file を、ローカルのマシン example 上にあるファイル example.file に追加します。
example% rsh lizard cat lizard.file >> example.file
次のコマンドは、リモートのマシン lizard 上にあるファイル lizard.file を、同じマシン lizard 上にあるファイル lizard.file2 に追加します。
example% rsh lizard cat lizard.file ">>" lizard.file2
次の終了ステータスが返されます。
正常終了。
エラーが発生した。
インターネットホストテーブル
信頼性のあるリモートホストとユーザー
システムパスワードファイル
アクセスを許可する Kerberos 主体を含むファイル
Kerberos 構成ファイル
属性についての詳細は、マニュアルページの attributes(5) を参照してください。
|
on(1), rlogin(1), ssh(1), telnet(1), vi(1), in.rshd(1M), hosts(4), hosts.equiv(4), krb5.conf(4), attributes(5), krb5_auth_rules(5), largefile(5), ip6(7P)
hosts.equiv に登録されているシステムのセキュリティーは、少なくともローカルシステムのセキュリティーと 同レベルである必要があります。セキュリティーレベルの低いシステムが hosts.equiv 中に 1 つでも存在していると、システム全体のセキュリティーが損なわれる可能性があります。
vi(1) のような対話型コマンドは実行できません。対話型コマンドは rlogin を使って実行してください。
停止シグナルは、ローカルの rsh プロセスだけを停止させます。これはバグだという議論があるかもしれませんが、現在のところ修正が大変困難です。その理由は複雑なので、ここでは説明を省きます。
現在のローカル環境は、リモートシェルに引き渡されません。
–n オプションを使用すると、原因を特定できないような問題が発生することがあります。次に例を示します。
example% rsh somehost dd if=/dev/nrmt0 bs=20b | tar xvpBf −
このコマンドを実行すると、シェルの状態がおかしくなります。つまり rsh の前に tar が終了してしまい、次に rsh コマンドが「壊れたパイプ」に書き込みを試みると、正常終了せずに、標準入力をめぐってシェルと競合します。–n オプションを指定して rsh を実行すれば、このような事態を防ぐことができます。
このバグは rsh がパイプラインの先頭で、標準入力を読み込まないときにだけ発生します。rsh が標準入力を読み込む必要があるときは、–n オプションを使用しないでください。例:
example% tar cf − . | rsh sundial dd of=/dev/rmt0 obs=20b
この場合、前述のような現象は起こりません。この場合に –n オプションを指定すると、rsh はパイプから読み込む代わりに、誤って /dev/null からの読み込みを試みます。
ほとんどの場合、ssh(1) は rsh よりも推奨されています。