Git Push 在几次推送后挂起

发布于 2024-12-05 21:34:52 字数 851 浏览 3 评论 0原文

我启动 Ubuntu Linux，打开终端，编辑一些代码，然后愉快地执行。

git push origin master

但是，在一段时间后（有时 30 分钟，有时几个小时），完全相同的命令将挂起（根本没有输出）。

当我尝试时

ssh -v [email protected]

，我得到以下响应：

OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /home/avitus/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master

然后它再次挂起。一旦我通过 SSH 连接到另一台服务器，我似乎就无法再使用 SSH 进行 git 了。有什么想法如何解决这个问题吗？每次都必须重新启动，这让我很痛苦。

更新：

当我从 ~/.ssh/config 中删除以下两行（旨在促进连接共享）时，问题就消失了

ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%r

原文

I start up Ubuntu Linux, open a terminal, edit some code, and happily execute

git push origin master

However, after some period of time (sometimes 30 mins, sometimes a few hours), the exact same command will hang (no output at all).

When I try

ssh -v [email protected]

I get the following response:

OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /home/avitus/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master

And then it hangs again. It seems as though I can no longer use SSH to git once I've SSH'ed to another server. Any ideas how to fix this? It is killing me having to reboot each time.

Update:

The problem goes away when I remove the following two lines (intended to facilitate connection sharing) from ~/.ssh/config

ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%r

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

哑 2024-12-12 21:34:52

只是将我的猜测从评论变成答案...

ssh -v 输出中的最后一行：

debug1: auto-mux: Trying existing master

...告诉您 SSH 已配置为看起来以便重用现有的 SSH 连接。我怀疑这种现有的连接最终会以某种方式陷入困境，这可以解释您所看到的行为。

此连接共享工具在 ssh_config 的 ControlMaster 部分中进行了描述(5)手册页。本质上，“主”SSH 会话在 /tmp 中创建一个套接字，以后的会话可以连接到该套接字，而不必再次执行潜在长度的身份验证步骤。您可以将此选项设置为auto，这意味着该套接字将自动创建和使用。

Just turning my guess from a comment into an answer...

The last line in the output of ssh -v:

debug1: auto-mux: Trying existing master

... tells you that SSH has been configured to look for an existing SSH connection to reuse. I suspect that this existing connection eventually gets stuck in some way, which would explain the behaviour you're seeing.

This connection sharing facility is described in the ControlMaster section of the ssh_config(5) man page. Essentially the "master" SSH session creates a socket in /tmp which later sessions can connect to instead of having to go through the potentially length authentication step again. You have this option set to auto, which means that this socket will be created and used automatically.

回复收藏 0 原文

呆橘 2024-12-12 21:34:52

我在这个问题上挣扎了一段时间，然后偶然发现了 GitHub 支持下的帮助页面：

https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port

转我的工作场所拥有防火墙/端口保护的正确神奇组合，“几乎”允许常规 Git SSH 访问 GitHub，即它“偶尔”工作但不可靠。 ;-b

通过我的 $HOME/.ssh/config 文件中的这个咒语，要通过 HTTPS 使用 SSH，我突然能够通过 GitHub 中的 SSH 密钥从命令行访问我的 GitHub 存储库：

Host github.com

User git

Hostname ssh.github.com

Port 443 

PreferredAuthentications publickey

IdentityFile /home/XXX/.ssh/github_id_rsa

TCPKeepAlive yes     # not sure if truly needed

IdentitiesOnly yes   # not sure if truly needed

享受吧！
啊啊啊啊啊啊啊啊啊啊啊:)

I struggled with this for a while before stumbling onto a help page buried under GitHub support:

https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port

Turns out my workplace had just the right magic combination of firewall/port protection to "almost" allow regular Git SSH access to GitHub, i.e. it worked "occasionally" but not reliably. ;-b

With this incantation in my $HOME/.ssh/config file, to use SSH Over HTTPS, I was suddenly able to access my GitHub repo from the command line via my SSH Key in GitHub:

Host github.com

User git

Hostname ssh.github.com

Port 443 

PreferredAuthentications publickey

IdentityFile /home/XXX/.ssh/github_id_rsa

TCPKeepAlive yes     # not sure if truly needed

IdentitiesOnly yes   # not sure if truly needed

Enjoy!
Jeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeem :)

回复收藏 0 原文

~没有更多了~