rshとpoll: protocol failure in circuit setup

ずいぶん前からsshばかり使うようになっているが、当然、sshよりもrshのほうが軽い。ローカルネットワークでデータの転送に使うという意味では、rshのほうがよいと思われる。

rshはパスワードが必要ないようにサーバ側の~/.rhostsを設定する他に、クライアント側のポート514番と1020番の周辺(?)を開けておく必要がある。そうしないと

poll: protocol failure in circuit setup

と言われてしまう。rloginにはこんなポートを開ける必要はなく、rshでもコマンドを指定しない(rloginと同じ)と必要はない。iptablesでデフォルトではこれらのポートは閉じられているわけで、はまりやすいポイントではないかと思う。

でも、514はshellだけど、1020のあたりはwell known portとは思えない。毎回変わるし。見てると、FTPみたいにrshのコマンド自体が割り当てをもらって指定しているような感じだ。認証とかに使っているのかもしれないな。

結局はrshを使おうと思ったらiptables -Fでフィルタを全部消して全開状態でやるということになるんだろうか。FTPならpassiveモードとなんとかモードがどうたら…という逃げ方があるんだけど。

コメント

  1. これとは全く関係ないかもしれないが、redhat のうんたらディストリビューションでは、rsh するとケルベロスがうんたらとか言われて閉口する。
    path の順位が /usr/bin より /usr/kerberos/bin の方が前に来ているのでケルベロスの rsh が呼ばれてしまうのだ。
    シェルの設定で強引に /usr/bin を一番前に持ってきているのだが……スマートじゃないなぁ。みんな困ってないのかなぁ。
    ああ、やっぱ関係ないね。

  2. > クライアント側のポート514番と1020番の周辺(?)を開けておく
    クライアントというよりは、サーバ側(in.rshd が動く方)では?
    あと、1020 番周辺とのことですが、これはクライアント側(rsh を実行する方)の 113 番に繋ぎに行ってます。ident 認証とかいうやつ。だから iptables で制御するならば、src のどっかから dst の 113 に行けるようにしておけばいいのでは?
    まぁ /etc/xinetd.d/rsh の log_on_success と log_on_failure を消しちゃってもいいんですが。

  3. サーバ側ではなく、クライアント側のポートを開ける必要があります(だからハマるんです)。log_on_successやlog_on_failureを消しても無駄です。
    長くなるので別のエントリに説明を書きます。

  4. 今日はまっていた者です。
    これは BSD r コマンドのエラーチャネルです。

    server:1024未満 —> client:1024未満

    という接続です。参考:「ファイアウォール構築 第 2 版」Vol.2 p.195—–

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です