“ssh example.com”挂起但“ssh example.com bash -i”不
每天我都会遇到一个非常奇怪的现象。
通过我的大学互联网连接，通过 ssh 连接到我的机器（“ssh example.com”）可以正常工作。
从我家的 adsl，“ssh example.com”我的控制台卡住了这条消息：
debug1: Server accepts key: pkalg ssh-rsa blen 533
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
有时它可能会让我进入，但在大多数情况下不会。 有趣的是，如果我执行“ssh example.com bash -i”，我会立即登录。
everyday I encounter a very strange phenomenon.
From my university internet connection, sshing to my machine ("ssh example.com") works without any problems.
From my home adsl, "ssh example.com" my console gets stuck with this message:
debug1: Server accepts key: pkalg ssh-rsa blen 533
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
Sometimes it might let me in but in most of the cases not.
The funny thing is that if I execute "ssh example.com bash -i" I get logged in immediately.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我终于找到了问题的根源。它与 SSH 服务类型 (ToS) TCP 数据包有关。
当您请求常规 ssh 终端时，ssh 将 TCP 数据包服务类型 (ToS) 设置为“交互式”。我住所的路由器会阻止这些数据包类型！
使用 netcat，隧道 TCP 数据包不会获得任何类型的服务指令。因此，如果您通过 netcat 传输所有 ssh 流量，则会将 TCP 数据包的 ToS 重置为默认值。
在 .ssh/config 中，您必须设置：
因此，每次您尝试 ssh 到 example.com 时，都会调用 netcat 并对数据包进行隧道传输。
I finally found the source of the problem. It has to do with SSH type of service (ToS) TCP packets.
When you ask for a regular ssh teminal, ssh sets the TCP packet type of service (ToS) to "interactive". My router in my residence blocks those packet types!
Using netcat, the tunneled TCP packets get no type of service directives. Thus, if you tunnel all your ssh traffic through netcat, you reset the ToS of the TCP packets to the default ones.
In .ssh/config, you have to set:
So, each time you try to ssh to example.com, netcat will be called and will tunnel the packets.
从 OpenSSH 5.7 开始，您只需将其添加到您的 ssh 配置文件（~/.ssh/config 或 /etc /ssh/ssh_config）：
这是解决 Asterios 发现的问题的更直接方法。
As of OpenSSH 5.7, you can just add this to your ssh config file (either ~/.ssh/config or /etc/ssh/ssh_config):
This is a more-direct way to work around the problem Asterios identified.
我刚刚遇到了同样的问题。尝试使用不同的 ssh 客户端登录以获取更多信息。 Linux 命令行客户端没有返回任何有用的消息，而 Putty 则返回“服务器拒绝分配 pty”。我用 mkdir /dev/pts 和 mount -a 修复了它。我不太确定它最初是如何变得如此混乱的。
顺便说一句， bash -l 应该像登录 shell 一样工作，因此您应该能够相当轻松地证明 Peter Westlake 的建议在您的情况下是正确还是不正确。
I've just had the same problem. Try logging in with a different ssh client for more information. Whereas the linux command-line client didn't come back with any useful message, Putty came back with "server refused to allocate pty". I fixed it with mkdir /dev/pts and mount -a. How it got that mucked up in the first place I'm less sure about.
BTW, bash -l should act like a login shell so you should be able to prove Peter Westlake's suggestion correct or incorrect in your case fairly easily.
两种情况之间的区别在于“bash -i”不会为您提供登录 shell，而只是运行 ssh 即可。您可以通过“man bash”了解“登录 shell”的详细信息，但最主要的是它运行 /etc/profile 和您的 .bash_profile。查看这些文件中是否有任何可能导致问题的内容。
The difference between the two cases is that "bash -i" does not give you a login shell but just running ssh does. You can "man bash" for details of what a "login shell" is, but the main thing is that it runs /etc/profile and your .bash_profile. Have a look in those files for anything that might be causing a problem.
也许服务器没有 ptys。
Maybe the server is out of ptys.