☰

发送环境变量会导致专有 SSH/SFTP 服务器删除会话

tag-icon • tag-icon ssh environment-variables sftp
发送环境变量会导致专有 SSH/SFTP 服务器删除会话

不预期/不支持来自客户端的环境变量的服务器是否有可能在注意到客户端发送此类变量时终止此类会话？

我已经捕获了 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 服务器的供应商提交错误报告。

相关内容