如何通过SSH协议诊断hg push失败
How to diagnose hg push failure via SSH protocol
我正在尝试将变更集推送到远程存储库，但命令似乎已发送但没有任何反应。
我正在使用 Windows 8.1，运行 最近版本的 Mercurial (4.2)。我可以使用 PuTTY 和 OpenSSH 客户端通过 SSH 连接到我的服务器，无论是使用密钥身份验证还是基于密码的身份验证。
我的 hgrc 文件有这个：
[ui]
...
ssh = ssh -i "path_to_id_file" -2 -C
[defaults]
...
push = --debug
这是我在命令行上得到的输出：
pushing to ssh://myuser@mydomain.com//var/hgrepos/projectx
running ssh -i "path_to_id_file" -2 -C myuser@mydomain.com "hg -R /var/hgrepos/projectx serve --stdio"
sending hello command
sending between command
在那之后的几分钟内，什么也没有发生。我期望必须将密码短语提供给我的私钥，就像我简单地键入 ssh myuser@mydomain.com 时发生的那样。 Ctrl+C 不执行任何操作：我必须关闭 window.
无论我使用密钥还是密码身份验证，推送总是在 "sending between command" 之后无限期挂起。在某些时候，我认为我的密钥密码或密码是预期的，但输入任何一个都没有产生任何积极的结果。
我多年来一直使用 HTTPS 管理此远程服务器及其上的存储库，并且 Mercurial 通过该协议按预期工作。我正逐渐转向基于密钥的身份验证，而 hg 是这条道路上的最后一步。
最新信息：hg clone 表现出相同的行为。
如果能提供诊断方面的帮助，我们将不胜感激。
编辑
我在服务器上启用了 SSH 日志，我在尾部 /var/log/secure 时得到了这个（这些行是我之前给出的 4 行的服务器端匹配）：
Jul 4 13:15:40 vpsxxxxx sshd[11654]: debug1: Forked child 15779.
Jul 4 13:15:40 vpsxxxxx sshd[15779]: Set /proc/self/oom_score_adj to 0
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: inetd sockets after dupping: 3, 3
Jul 4 13:15:40 vpsxxxxx sshd[15779]: Connection from 176.188.xx.xx port 64160
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: Client protocol version 2.0; client software version OpenSSH_7.5
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: match: OpenSSH_7.5 pat OpenSSH*
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: Enabling compatibility mode for protocol 2.0
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: Local version string SSH-2.0-OpenSSH_5.3
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: permanently_set_uid: 74/74
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEXINIT sent
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEXINIT received
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: kex: client->server aes128-ctr umac-64@openssh.com zlib@openssh.com
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: kex: server->client aes128-ctr umac-64@openssh.com zlib@openssh.com
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_NEWKEYS sent
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: expecting SSH2_MSG_NEWKEYS
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_NEWKEYS received
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: KEX done
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: userauth-request for user userx service ssh-connection method none
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: attempt 0 failures 0
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: PAM: initializing for "userx"
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: PAM: setting PAM_RHOST to "176.188.xx.xx"
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: PAM: setting PAM_TTY to "ssh"
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: userauth_send_banner: sent
除非我以错误的方式解释它，否则服务器似乎处于用户身份验证步骤，而客户端 Mercurial 已经在尚未打开的通信线路上发送命令，因为用户尚未打开已通过身份验证。
我终于在使用 SSH 方面取得了成功（同样，我几年前就做到了）。
问题似乎是使用 OpenSSH 包中的 ssh.exe，或者（这在我今天阅读的下面的网页上有记录，它帮助我摆脱了这个泥潭）服务器的密钥尚未缓存。然而，除了之前通过 Putty、MobaXterm 和 ssh.exe.
进行的大量连接之外，我还手动连接到服务器，如问题中所述
所有需要的（参见 https://www.mercurial-scm.org/wiki/WindowsInstall）是 Putty 包和一些配置。
参考文献：
- http://www.codza.com/mercurial-with-ssh-setup-on-windows
- https://www.mercurial-scm.org/wiki/AccessingSshRepositoriesFromWindows
第二个特别简洁，对我帮助最大。
至此，我的.hgrc文件的相关内容如下：
[ui]
...
ssh = D:\Programs\putty\plink.exe -ssh -agent -2 -C -i "path-to-ppk-file"
我正在转换为 SSH 而不是 HTTPS 的本地存储库的 hgrc 文件包含：
[paths]
default-push=ssh://username@domain.tld:1234//var/hgrepos/projectx
请注意，Mercurial 将分解该 URI 并将适当的参数呈现给 ui.ssh 中指示的命令。例如，hg clone ssh://username@domain.tld:1234//var/hgrepos/projectx 在命令行中产生此输出 window:
G:\Data\Temp>hg clone ssh://username@domain.tld:1234//var/hgrepos/projectx
running D:\Programs\putty\plink.exe -ssh -agent -2 -C -i "path-to-ppk-file" username@domain.tld -P 1234 "hg -R /var/hgrepos/projectx serve --stdio"
sending hello command
sending between command
remote: 329
remote: capabilities: lookup changegroupsubset branchmap pushkey known getbundle unbundlehash batch stream bundle2=HG20%0Achangegroup%3D01%2C02%0Adige
sts%3Dmd5%2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgtagsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2
Chttps unbundle=HG10GZ,HG10BZ,HG10UN
remote: 1
destination directory: projectx
query 1; heads
sending batch command
requesting all changes
sending getbundle command
bundle2-input-bundle: with-transaction
bundle2-input-part: "changegroup" (params: 1 mandatory 1 advisory) supported
adding changesets
add changeset 279e0cde0d10
....
我正在尝试将变更集推送到远程存储库，但命令似乎已发送但没有任何反应。
我正在使用 Windows 8.1，运行 最近版本的 Mercurial (4.2)。我可以使用 PuTTY 和 OpenSSH 客户端通过 SSH 连接到我的服务器，无论是使用密钥身份验证还是基于密码的身份验证。
我的 hgrc 文件有这个：
[ui]
...
ssh = ssh -i "path_to_id_file" -2 -C
[defaults]
...
push = --debug
这是我在命令行上得到的输出：
pushing to ssh://myuser@mydomain.com//var/hgrepos/projectx
running ssh -i "path_to_id_file" -2 -C myuser@mydomain.com "hg -R /var/hgrepos/projectx serve --stdio"
sending hello command
sending between command
在那之后的几分钟内，什么也没有发生。我期望必须将密码短语提供给我的私钥，就像我简单地键入 ssh myuser@mydomain.com 时发生的那样。 Ctrl+C 不执行任何操作：我必须关闭 window.
无论我使用密钥还是密码身份验证，推送总是在 "sending between command" 之后无限期挂起。在某些时候，我认为我的密钥密码或密码是预期的，但输入任何一个都没有产生任何积极的结果。
我多年来一直使用 HTTPS 管理此远程服务器及其上的存储库，并且 Mercurial 通过该协议按预期工作。我正逐渐转向基于密钥的身份验证，而 hg 是这条道路上的最后一步。
最新信息：hg clone 表现出相同的行为。
如果能提供诊断方面的帮助，我们将不胜感激。
编辑
我在服务器上启用了 SSH 日志，我在尾部 /var/log/secure 时得到了这个（这些行是我之前给出的 4 行的服务器端匹配）：
Jul 4 13:15:40 vpsxxxxx sshd[11654]: debug1: Forked child 15779.
Jul 4 13:15:40 vpsxxxxx sshd[15779]: Set /proc/self/oom_score_adj to 0
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: inetd sockets after dupping: 3, 3
Jul 4 13:15:40 vpsxxxxx sshd[15779]: Connection from 176.188.xx.xx port 64160
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: Client protocol version 2.0; client software version OpenSSH_7.5
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: match: OpenSSH_7.5 pat OpenSSH*
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: Enabling compatibility mode for protocol 2.0
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: Local version string SSH-2.0-OpenSSH_5.3
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: permanently_set_uid: 74/74
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEXINIT sent
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEXINIT received
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: kex: client->server aes128-ctr umac-64@openssh.com zlib@openssh.com
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: kex: server->client aes128-ctr umac-64@openssh.com zlib@openssh.com
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_NEWKEYS sent
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: expecting SSH2_MSG_NEWKEYS
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: SSH2_MSG_NEWKEYS received
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: KEX done
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: userauth-request for user userx service ssh-connection method none
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: attempt 0 failures 0
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: PAM: initializing for "userx"
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: PAM: setting PAM_RHOST to "176.188.xx.xx"
Jul 4 13:15:40 vpsxxxxx sshd[15779]: debug1: PAM: setting PAM_TTY to "ssh"
Jul 4 13:15:40 vpsxxxxx sshd[15780]: debug1: userauth_send_banner: sent
除非我以错误的方式解释它，否则服务器似乎处于用户身份验证步骤，而客户端 Mercurial 已经在尚未打开的通信线路上发送命令，因为用户尚未打开已通过身份验证。
我终于在使用 SSH 方面取得了成功（同样，我几年前就做到了）。
问题似乎是使用 OpenSSH 包中的 ssh.exe，或者（这在我今天阅读的下面的网页上有记录，它帮助我摆脱了这个泥潭）服务器的密钥尚未缓存。然而，除了之前通过 Putty、MobaXterm 和 ssh.exe.
所有需要的（参见 https://www.mercurial-scm.org/wiki/WindowsInstall）是 Putty 包和一些配置。
参考文献：
- http://www.codza.com/mercurial-with-ssh-setup-on-windows
- https://www.mercurial-scm.org/wiki/AccessingSshRepositoriesFromWindows
第二个特别简洁，对我帮助最大。
至此，我的.hgrc文件的相关内容如下：
[ui]
...
ssh = D:\Programs\putty\plink.exe -ssh -agent -2 -C -i "path-to-ppk-file"
我正在转换为 SSH 而不是 HTTPS 的本地存储库的 hgrc 文件包含：
[paths]
default-push=ssh://username@domain.tld:1234//var/hgrepos/projectx
请注意，Mercurial 将分解该 URI 并将适当的参数呈现给 ui.ssh 中指示的命令。例如，hg clone ssh://username@domain.tld:1234//var/hgrepos/projectx 在命令行中产生此输出 window:
G:\Data\Temp>hg clone ssh://username@domain.tld:1234//var/hgrepos/projectx
running D:\Programs\putty\plink.exe -ssh -agent -2 -C -i "path-to-ppk-file" username@domain.tld -P 1234 "hg -R /var/hgrepos/projectx serve --stdio"
sending hello command
sending between command
remote: 329
remote: capabilities: lookup changegroupsubset branchmap pushkey known getbundle unbundlehash batch stream bundle2=HG20%0Achangegroup%3D01%2C02%0Adige
sts%3Dmd5%2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgtagsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2
Chttps unbundle=HG10GZ,HG10BZ,HG10UN
remote: 1
destination directory: projectx
query 1; heads
sending batch command
requesting all changes
sending getbundle command
bundle2-input-bundle: with-transaction
bundle2-input-part: "changegroup" (params: 1 mandatory 1 advisory) supported
adding changesets
add changeset 279e0cde0d10
....