奇怪的SSH问题，ssh与-t一起使用，但在没有它的情况下冻结

13

当我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 and和（或） 更改sshd_config为一个
我检查了路由
我有一位网络专家进行了检查tcpdump，但无济于事（尽管确实有很多重新传输）

我真的想不到

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

shell ssh login

— 先生
source

中有任何match陈述sshd_config吗？仅sshd运行一个实例吗？

— Hauke Laging

3

如果从本地ssh会怎样？从同一台物理计算机上托管的VM？来自同一网段？如果在其他端口上运行sshd的另一个实例？你有什么不寻常的.ssh/authorized_keys，如command=…？您是否已通过所有防火墙规则，以查看是否可能意外阻止了某些SSH数据包？

— 吉尔斯（Gillles）“所以-别再邪恶了” 2014年

1

SSH连接挂起时能否按Ctrl + C并显示提示？该提示将不是您的常规提示。如果这是问题所在，则您的/etc/profile.d/*或/etc/bashrc文件中可能存在问题。

— slm

1

是否按“ <Enter>〜”？做任何事情？这是三个按键，输入波浪号questionmark。

— godlygeek 2014年

1

当您可以登录时，/ etc / passwd中的默认shell是什么？如果可以使用bash shell登录，那么听起来默认外壳是bash shell以外的东西。

— Warwick

5

这可能来自配置文件中的问题。
当您与ssh -t /bin/bash 您的外壳程序连接时，将不会“登录”，它将/etc/profile不会提供，~/.profile以及和的源代码~/.bashrc。

因此，在连接之后，将外壳置于调试模式，然后获取每个文件的源代码以查找内部阻塞的内容：

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

编辑

请注意，我错了，.bashrc文件将由任何交互式外壳程序提供（因此此处仅profile，profile.d文件很重要）。

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

1）ssh连接（config，...）
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是最大调试级别，您可以对其进行调整）

我得到了该链接，更加详细。

— 伊曼纽尔
source

我非常希望这是答案，即使不是，也谢谢您对差异的解释，因为这将帮助我解决问题。我尝试移动所有与配置文件相关的内容，甚至使用空白的/ root文件夹，但没有任何效果（即使是不同的登录shell）。

— MisterG 2014年

2

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

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

但是请注意，这是不得已的方法 。我的特殊之处是ssh服务器在同一子网中工作，但不在同一子网中，而ssh -t'/ bin / bash'在任何地方都可以工作。

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

因此，如果您正在寻找这个答案，请首先尝试上面的其他答案，并且仅当您遇到像我这样的怪异现象时，这才可能有所帮助。

因此，感谢您的所有帮助。我尝试了一切，并教会了我负载，然后让我确认它与服务器无关（这是我所希望的一切）。

谢谢大家的帮助

— 先生
source

1

在执行操作时ssh some_user@some_host /bin/bash，您要做的是启动some_user的shell（/etc/passwd在some_host中定义），然后/bin/bash从该shell中执行给定的命令。

现在，some_user的外壳程序（假设它也是bash）不是以交互方式启动的（而是执行给定的命令）。因此，它不会分配pty（伪终端），这意味着发出的命令不会使用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作为命令传递，因为无论如何它都应该位于用户默认外壳程序的路径上）

— 星际争霸
source

1

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

在源服务器或目标服务器上将MTU从1500减少到1400后，它才能工作。

/sbin/ip link set dev eth0 mtu 1400

— 周伟
source