クライアントから環境変数を期待/サポートしていないサーバーがクライアントがそのような変数を送信していることを発見した場合、そのようなセッションを終了することは可能ですか?
sftpクライアントのデバッグレベルのログをキャプチャし、最後まですべてがうまくいっています。つまり、成功した認証、sftpサブシステムに対する要求です。この段階で、クライアントが環境変数を送信している間、サーバーはセッションを閉じます。
他のSFTPクライアントは環境データを送信しないため、セッションが完了するまで実行されます。
openssh s / wのAcceptEnv、SendENv機能を知っていますが、独自のsftp / sshサーバーに代わってこの動作(envデータを送信するクライアントからのセッションの削除)を保証する必要がありますか?
debug1: channel request 0: subsystem
debug2: callback done
debug1: channel 0: open confirm rwindow 32000 rmax 35000
debug1: channel_free: channel 0: client-session, nchannels 1
debug3: channel_free: status: The following connections are open:
#0 client-session (t4 r43 i0/0 o0/0 fd 6/7)
debug3: channel_close_fds: channel 0: r 6 w 7 e 8
debug1: fd 0 clearing O_NONBLOCK
debug2: fd 1 is not O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
Connection to xyz.com closed by remote host.
答え1
サーバー管理者がそのような要求があるときに何が起こるように具体的に構成できない限り、接続を閉じることは明らかに過剰反応です。私はこれが他のSSH2プロトコルオプションのように扱われたいと思います。サーバーがクライアントが要求したオプションを受け入れないか理解していない場合、サーバーはそのオプションを無視して許可できるオプションを引き続き使用する必要があります。
先例があります。 OpenSSHに新しい暗号化アルゴリズムが追加されると、SSHの一部のファームウェア実装(ILOM / iLO / iRMCなどのリモート管理ハードウェア)は、クライアントの暗号化方法のリストに十分な大きさのバッファを割り当てず、これを実行できません。ネゴシエート可能な暗号化方式の数がクライアント構成によって短縮されない限り、接続が確立される。これは間違いなくバグと見なされ、可能であれば将来のファームウェアリリースで修正される予定です。
独自のSSHサーバーベンダーにバグレポートを送信することをお勧めします。