如何在不丢失错误消息的情况下抑制 /etc/issue？

Question

是否可以告诉 ssh 客户端/etc/issue在连接到远程主机时不打印到 stdout 的连接，而是打印出任何其他诊断（例如错误）消息？

使用ssh -q或使用LogLevel quietin 会~/.ssh/config抑制/etc/issue打印，但也会关闭错误消息。我也试过touching ~/.hushlogin- 停止/etc/motd打印，但不影响/etc/issue.

最明显的解决方案是删除/etc/issue，但公司政策规定文件在那里，并带有有关未经授权访问的可怕警告。这是没有商量余地的。不幸的是，我有一堆脚本通过 ssh 运行在相当多的主机上，并且日志文件 a) 非常大并且 b) 充满了法律术语。由于很多东西都在无人看管的情况下运行，我不想丢失任何打印的错误消息。

Answer 1

是   添加~/.ssh/config包含以下内容的文件：

LogLevel ERROR

OpenSSH 显示/etc/issue来自远程服务器的内容。该参数禁用此显示。当公司远程 Git repo 作为恼人的安全警告时非常有用。

手册ssh config页说：

LogLevel

给出从 ssh(1) 记录消息时使用的详细级别。可能的值是：QUIET，FATAL，ERROR， INFO，VERBOSE，DEBUG，DEBUG1，DEBUG2，和DEBUG3。默认值为INFO. DEBUG并且DEBUG1是等价的。 DEBUG2和DEBUG3每个指定较高水平的详细输出的。

额外的技巧   也添加到您的~/.ssh/config

Host *
#    StrictHostKeyChecking no
     StrictHostKeyChecking accept-new

这可以防止另一个烦人的消息。连接到新主机时，以下安全问题会阻止正在进行的连接。上面的技巧总是假设yes. 然而在实践中你总是回答yes，不是吗？

The authenticity of host 'newhostname (11.222.33.44)' can't be established.
RSA key fingerprint is aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:00.
Are you sure you want to continue connecting (yes/no)?

编辑：正如Chris Adams所指出的，使用StrictHostKeyChecking no可能允许中间人攻击，更好地使用，StrictHostKeyChecking accept-new如https://man.openbsd.org/ssh_config.5#StrictHostKeyChecking 中所述。

Answer 2

不。

当主机发回文本行时，SSH 客户端如何知道哪些行来自主机的 /etc/issue，哪些是更有趣的消息？不可以。