클라이언트로부터 환경 변수를 기대/지원하지 않는 서버가 클라이언트가 그러한 변수를 보내는 것을 발견하면 그러한 세션을 종료하는 것이 가능합니까?
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 서버 공급업체에 버그 보고서를 제출하는 것이 좋습니다.