rshに「poll:プロトコルが回路設定に失敗しました」と表示されます。なぜですか?

rshに「poll:プロトコルが回路設定に失敗しました」と表示されます。なぜですか?

最初はrshはうまくいきましたが、いくつかの変更を加えた後にいくつかのエラーが表示されました。 [変更はこの質問の最後に表示されます。参照] 私も同じ内容を共有しています。

注文する

$/usr/bin/rsh localhost ulimit -n

出力

poll: protocol failure in circuit setup

この問題に直面した後、私はフォローしました。このリンクしかし、何の助けも受けていません。

うまく機能していましたが、少し変更を加えたので、協会をクリックすると、上記のような出力が表示されます。これですべての変更が元に戻りますが、同じ出力が表示されます。なぜ?

上記のリンクを見て左側の行はファイルに追加した行です。

/etc/pam.d/login:       session    required     pam_limits.so
/etc/pam.d/sshd:        session    required     pam_limits.so
/etc/pam.d/su:          session    required     pam_limits.so
/etc/pam.d/system-auth: session    required     pam_limits.so

ここ私がやろうとしていることへのリンクです。

編集者No.1

strace -o log.txt rsh localhost pwd、一部の出力ラインは次のとおりです。

connect(3, {sa_family=AF_INET, sin_port=htons(514), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
bind(4, {sa_family=AF_INET, sin_port=htons(1022), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(4, 1)                            = 0
write(3, "1022\0", 5)                   = 5
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 ([{fd=3, revents=POLLIN|POLLERR|POLLHUP}])
write(2, "poll: protocol failure in circui"..., 40) = 40
close(4)                                = 0
close(3)                                = 0
rt_sigprocmask(SIG_SETMASK, [], [URG], 8) = 0
exit_group(1) 

2回修正

注文する - strace ~/rshd.trace in.rshd

出力

execve("/usr/sbin/in.rshd", ["in.rshd"], [/* 22 vars */]) = 0
brk(0)                                  = 0x2b3054ec2000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b303671d000
uname({sys="Linux", node="jhamb.XXX.XXX", ...}) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b303671e000
arch_prctl(ARCH_SET_FS, 0x2b303671e6d0) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

答え1

rshは非常に珍しい問題を持つ非常に奇妙なプロトコルです。 (私の考えでは、PASVではなくftpが私が見た唯一のTCPベースのプロトコルのようです。)サーバーへの接続を開いた後、サーバーはクライアントのTCPを再度開く必要があります。つながるこれは、rshプロトコルが通常のTCP接続を介して標準出力を返し、奇妙なバックチャネル接続を介して標準エラーを返すためです。

明らかに、ファイアウォールがどこにある今日の世界では、この方法の効果は非常に低いです。あなたとターゲットサーバーの間の一部のファイアウォールがそのバックチャネル接続を拒否しているようです。一部のファイアウォールにはこれを可能にするrshプロトコルステータス追跡機能がありますが、可能であっても通常はオンになりません。

これが(他の多くの理由の中で)rshが死んで、誰もがsshに移動した理由です。 sshには、同じ接続を介して複数の出力ストリームを多重化するように設計されたより良い(より複雑ですが)プロトコルがあります。

これが最初のリンクでiptablesをオフにするように言う理由です。これにより、バックチャネル接続をブロックするファイアウォールが無効になります。

答え2

理由:

問題は、複数のrshが同時に実行されていることです。

解決策:

rshを再起動して、

xinetdサービスを再起動してください

関連情報