我们有一个AWS托pipe的Bitbucket服务器实例。 从其他AWS服务器(在另一个地区),通过SSH的git克隆将失败
ssh: connect to host (hostname) port 7999: Connection refused
但是,AWS中的其他服务器(与Bitbucket服务器位于同一区域)可以使用相同的URL成功通过SSH进行克隆。
其他信息:
Bitbucket绝对是听取端口7999:
$ sudo netstat -tnlp | grep :7999 tcp6 0 0 :::7999 :::* LISTEN 20707/java
(进程20707是主要的Bitbucket进程)
Bitbucket作为反向代理在Apache后面运行,以提供SSL。
克隆实例上端口7999上的tcpdump的结果:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:56:53.348387 IP (tos 0x0, ttl 64, id 61715, offset 0, flags [DF], proto TCP (6), length 60) (cloning server's hostname).38606 > (bitbucket server's hostname).irdmi2: Flags [S], cksum 0x2799 (incorrect -> 0xb1db), seq 3675985409, win 26883, options [mss 8961,sackOK,TS val 1512892178 ecr 0,nop,wscale 7], length 0 16:56:53.489908 IP (tos 0x0, ttl 252, id 37586, offset 0, flags [none], proto TCP (6), length 40) (bitbucket server's hostname).irdmi2 > (cloning server's hostname).38606: Flags [R.], cksum 0x24e4 (correct), seq 1472002966, ack 3675985410, win 26883, length 0
ssh'ing从克隆服务器到Bitbucket的结果:
$ sudo ssh -vvv -p 7999 ssh://[email protected] OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /root/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 56: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to stash.tddevops.com [172.24.16.201] port 7999. debug1: connect to address 172.24.16.201 port 7999: Connection refused ssh: connect to host stash.tddevops.com port 7999: Connection refused
Bitbucket服务器上的tcpdump在尝试克隆时不显示数据。
从https://serverfault.com/a/288493/442063 :
由于TCP校验和卸载function,您会看到“不正确的”校验和。 传出TCP数据包的校验和字段不是由操作系统预先计算的,而是设置为0,并留给NIC处理器进行计算。 Wireshark FAQ有更详细的解释。
这可能会有所帮助,但是您的问题听起来像是防火墙问题。 确保您没有在此托pipe的AWS服务器上运行内部防火墙并不会造成伤害。 不知道你正在运行什么操作系统,我不能真正推测要寻找什么。 许多Linux操作系统使用iptables。 例如,您可以在这里看到如何closures和禁用Oracle Linux或Redhat Linux的防火墙。
我发现这个问题; 这是我们安全部门防火墙的一个外部问题。 无需在克隆服务器或Bitbucket服务器上更改任何内容。