☰

奇怪的 SSH 问题，ssh 使用 -t 可以工作，但没有它就会冻结

tag-icon • tag-icon shell ssh login
奇怪的 SSH 问题，ssh 使用 -t 可以工作，但没有它就会冻结

当我ssh进入我的一台服务器时，它似乎已登录，但在给出提示之前挂起 ( message debug2: shell request accepted on channel 0 is the last log entry)。

尽管奇怪的是，当不起作用ssh -t "/bin/bash"时却起作用。ssh

到目前为止我发现了什么

  • 我可以正常从同一地理位置的服务器登录
  • 如果我ssh -t '/bin/bash'- 我可以从任何位置完美登录。
  • 如果我使用rsync 到服务器，它似乎可以工作，然后锁定
  • 如果我使用rsync 从服务器，运行没有问题

我尝试过的

  • 删除或更改所有登录选项.profile，.bashrc /etc/profile
  • 改变ssh_config 和/或 sshd_config到一台运行良好的相同服务器
  • 我检查了路由
  • 我请了网络专家检查，tcpdump但无济于事（尽管似乎确实有很多重传）

我实在想不出其他什么了

除了狡猾的网卡驱动程序/固件之外。

答案1

这可能来自配置文件中的问题。
当你连接ssh -t /bin/bash 你的 shell 时，它不会“登录”，它不会来源/etc/profile，也~/.profile不会 ~/.bashrc......

因此，连接后，将 shell 置于调试模式，然后对每个文件进行源操作以查找内部阻塞的内容：

set -x 
. /etc/profile 
...and so on

编辑

请注意，我错了，.bashrc 文件将由任何交互式 shell 获取（因此这里只有配置文件、profile.d 文件很重要）。

尝试列出连接过程的不同阶段。像这样的东西

1）ssh 连接（配置，...）
2）登录（PAM，tty，wtmp，...）
3）启动 shell（配置文件，主目录访问，...）

要检查 (1)，您可以在调试模式下启动 sshd 守护进程。为此，您需要启动另一个 sshd，侦听专用端口（不在端口 22 上，因此无需停止常规 sshd 守护进程）。

# /usr/sbin/sshd -p 2222 -ddd

该 sshd 将只接受一个连接并且不会进入后台。打开另一个终端并连接到该 ssh 会话。

# ssh -vvv -p 2222 user@host

您可以将收到的消息与同一品牌的另一台服务器的消息进行比较。然后你就知道问题是否出在ssh端了。

（-ddd和-vvv是最大调试级别，您可以调整）

我明白了关联，更详细。

答案2

我的问题的答案 原来是网络问题。我最终发现，通过将所有网卡的 MTU 降低一点，问题就消失了。

最有可能的是该网络的某些配置错误，但我现在可以证明这一点并将其移交给网络团队（他们一直告诉我这是服务器问题）。

但请注意，这是最后的手段 我的特点是 ssh 服务器在同一子网中工作，但不在其外部，并且 ssh -t '/bin/bash' 可以在任何地方工作。

我也有 rsyncs，可以正常启动，但在某些时候只是挂起，或断开连接。

因此，如果您正在查看这个答案，请先尝试上面的其他答案，并且只有当您遇到像我这样的奇怪问题时，这才可能有所帮助。

所以感谢所有的帮助。我尝试了一切，它教会了我很多东西，并让我确认它与服务器无关（这就是我所希望的一切）。

所以感谢所有提供帮助的人

答案3

我最近使用嵌套虚拟化平台时遇到了同样的问题。

将源服务器或目标服务器上的 MTU 从 1500 减少到 1400 后即可工作。

/sbin/ip link set dev eth0 mtu 1400

答案4

当你这样做时ssh some_user@some_host /bin/bash，你所做的就是启动某个用户的 shell（定义于/etc/passwdon某个主机)，然后/bin/bash从该 shell 中执行给定的命令 。

现在，某个用户的 shell（我们假设它也是bash）没有以交互方式启动（而是执行给定的命令）。所以它不会分配 pty (a伪终端），这意味着没有 pty 可供发出的命令使用，因此它以非交互方式启动。

在示例中，请求的/bin/bash命令已启动，但似乎挂起。

您可以通过要求ssh创建一个 pty 来修复此问题，以便 shell 及其子进程可以使用该 pty。这就是作用-t。

    $ ssh -t some_user@some_host bash

您还可以通过强制命令创建 pty 来解决此问题。对于bash，您可以通过传递-i参数来完成此操作。以下命令行也应该有效：

$ ssh some_user@some_host bash -i

但请注意，在后一种情况下，shell 无法访问/dev/tty，这会导致警告：

bash: no job control in this shell

原因如下：这里。这可能是也可能不是问题，具体取决于您计划在 shell 中执行的操作，但使用ssh -t可能是更好的选择。

（请注意，您可以仅bash作为命令传递，因为无论如何它都应该位于用户默认 shell 的路径上）

相关内容