After updating to Mojave 10.14.1, all ssh connections fail: terminal ssh, scp, git, etc., all get a "broken pipe":

 ssh myserver -v
 OpenSSH_7.8p1, LibreSSL 2.7.3
 debug1: Reading configuration data /Users/pablo/.ssh/config
 debug1: /Users/pablo/.ssh/config line 137: Applying options for myserver
 debug1: Reading configuration data /etc/ssh/ssh_config
 debug1: /etc/ssh/ssh_config line 48: Applying options for *
 debug1: Connecting to myserver port 22.
 debug1: Connection established.
 debug1: identity file /Users/pablo/.ssh/myserver.pem type -1
 debug1: identity file /Users/pablo/.ssh/myserver.pem-cert type -1
 debug1: Local version string SSH-2.0-OpenSSH_7.8
 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
 debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.1 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
 debug1: Authenticating to myserver:22 as 'ubuntu'
 debug1: SSH2_MSG_KEXINIT sent
 debug1: SSH2_MSG_KEXINIT received
 debug1: kex: algorithm: curve25519-sha256
 debug1: kex: host key algorithm: ecdsa-sha2-nistp256
 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
 debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
 debug1: Server host key: ecdsa-sha2-nistp256 SHA256:8/V/EyMKSlHjnDpF5v/ume45376635342324
 debug1: Host 'myserver' is known and matches the ECDSA host key.
 debug1: Found key in /Users/pablo/.ssh/known_hosts:62
 debug1: rekey after 134217728 blocks
 debug1: SSH2_MSG_NEWKEYS sent
 debug1: expecting SSH2_MSG_NEWKEYS
 debug1: SSH2_MSG_NEWKEYS received
 debug1: rekey after 134217728 blocks
 debug1: SSH2_MSG_EXT_INFO received
 debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
 debug1: SSH2_MSG_SERVICE_ACCEPT received
 debug1: Authentications that can continue: publickey
 debug1: Next authentication method: publickey
 debug1: Trying private key: /Users/pablo/.ssh/myserver.pem
 debug1: Authentication succeeded (publickey).
 Authenticated to myserver ([xx.xx.xx.xx]:22).
 debug1: channel 0: new [client-session]
 debug1: Requesting no-more-sessions@openssh.com
 debug1: Entering interactive session.
 debug1: pledge: network
 debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
 debug1: Sending environment.
 debug1: Sending env LANG = es_ES.UTF-8
 packet_write_wait: Connection to port 22: Broken pipe

after some research I found that adding this config to my ssh config file makes it work:

 Host *
     IPQoS lowdelay throughput
  • 1
    Sounds like your router doesn't recognize DSCP. Which is surprising that it's still a problem 20 years later – the router could have just ignored unknown values, like everyone else does, but for some reason it decided to terminate the connection instead. Perhaps it's an "anti-attack" feature gone wrong? – grawity Nov 8 '18 at 8:51
  • 1
    I have seen some problems with this ssh... And no, I think it's not the router. Other macs and linux in the same network can connect through ssh to the machine I cannot – Pablo Romeu Nov 8 '18 at 10:09
  • 2
    How has this not been more publicly known?! Are we the only people in the world that use SSH and Mojave? This broke my Git using GitHub how have we been the only ones with issues?! How does this stuff happen?! – Sukima Nov 13 '18 at 16:12
  • 1
    Just have to say I have two routers and both have had their firmware updated only a month ago. I find it very hard to believe that is the issue. I also have several computers using SSH and only my (just today updated) Mojave Mac has an issue. I cannot fathom why the answer here fixes the issue but it does. Obviously, Apple must have buggered something up. – Sukima Nov 13 '18 at 16:45
  • @Sukima I think it has to do with the SSH version in Mojave. github.com/vmware/open-vm-tools/issues/287 – Pablo Romeu Nov 14 '18 at 11:31

I had the same issue with you.
I managed to short term fix it by adding the following option.
-o ProxyCommand='nc %h %p'

  • 1
    This is just a way of avoiding having SSH set the IPQoS flags by using netcat to open the TCP connection instead. the IPQoS solution is more direct. – Perry Dec 19 '18 at 18:30

Adding this to .ssh/config solved it for me:

Host *
  • This isn't the problem. The problem is the IPQoS issue. – Perry Dec 18 '18 at 22:39

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.