Trying to git clone via SSH but getting broken pipe error

Question

I am having some strange issues trying to git clone one of my public GitHub repositories because of a weird issue. I know it's not an issue with my key, because I've taken the same key from another VM and just simply fixed its permissions. This is the error that I get when trying to use SSH:

[root:kali:~/scripts]# ssh -T [email protected]_write_wait: Connection to 192.30.253.112 port 22: Broken pipe 

Suggestion 1

Reference: https://gitlab.com/gitlab-com/support-forum/issues/129

Tried to add the following to an /etc/ssh/ssh_config file:

Host * ServerAliveInterval 120 TCPKeepAlive no 

and no luck. I've even tried changing TCPKeepAlive to yes, and the same thing happens.

My DNS server is set to 8.8.8.8, so not quite sure that's the issue. I can git clone the http URL, just not the SSH URL.

Suggestion 2

I also tried to run the ssh command with the verbose option, and according to the output, it looks like it actually authenticates successfully, as shown below:

debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: Authentication succeeded (publickey). Authenticated to github.com ([192.30.253.113]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: pledge: network debug1: Sending environment. debug1: Sending env LANG = C.UTF-8 debug1: Sending env LC_CTYPE = C.UTF-8 packet_write_wait: Connection to 192.30.253.113 port 22: Broken pipe 

Any idea what else could be going wrong here?

Answer 1

I don't know who this guy is, but bless him! This worked for me: https://blog.bchoy.me/post/2018-09-11-vmware-ssh-bug/

Put this in your ~/.ssh/config

Host *    ServerAliveInterval 600    TCPKeepAlive yes    IPQoS=throughput 

He has a link to some discussion about the IPQoS parameter -- which fixed it for me.

Answer 2

The solution

@crunk1 had the right answer for me, but I didn't need all of the settings he listed. Minimally, in ~/.ssh/config I just had to set:

Host *    IPQoS=throughput 

Info on IPQoS

That fixed my problem, but then all I wanted to know was what the heck IPQoS is. I couldn't find a simple explanation anywhere (this thread is the top hit for ipqos on SO), but there is at least some info out there.

• The ssh_config man page describes the IPQoS option we set above, and lists all of its valid values.

• The Debian docs describe troubleshooting a similar situation to that of the OP. In their case, they recommend

  Host *     IPQoS=0x00 

as the fix. Not sure what the difference is.

• Finally, the openssh specifications page lists has spec RFC8325, which describes QoS (quality of service) in great detail. Not so simple, but from what I can glean the idea is that, on connection, modern versions of the openssh server will communicate a ToS (type of service), which somehow has to align with your client's QoS settings.