Maybe the keepalive defaults got changed? All past references to the issue refer to some sort of keepalive to avoid the issue. For example [1]
Be aware that some suggestions on [1] configure the sever, while your issue is on the client side (at least that is where the upgrade happened. You could also run your failing ssh connection with debug enabled, sometimes a message helps to identify the issue $ ssh -vvv x.x.x.x You could check if the defaults changed by comparing your old and new setup with -G like: $ ssh -G x.x.x.x That will report the configs used. I compared 18.10 and 19.04 and found those: $ diff ssh.old ssh.new 3a4 > addkeystoagent false 36d36 < useprivilegedport no 47,49c47,50 < hostkeyalgorithms ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa < hostbasedkeytypes ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa < kexalgorithms curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 --- > hostkeyalgorithms > ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa > hostbasedkeytypes > ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa > kexalgorithms > curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 > casignaturealgorithms > ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa 52c53 < pubkeyacceptedkeytypes ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa --- > pubkeyacceptedkeytypes > ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa 68c69 < ipqos lowdelay throughput --- > ipqos af21 cs1 70a72 > syslogfacility USER I see nothing obvious, if anything then the change to ipqos from < ipqos lowdelay throughput to > ipqos af21 cs1 This might be interesting since one of the messages at [1] said [2] $ ssh -o IPQoS=throughput user@host Could you try if that resolves your issue. If yes we need to find why the default was changed and if we want to revert it or not. [1]: https://askubuntu.com/questions/127369/how-to-prevent-write-failed-broken-pipe-on-ssh-connection [2]: https://askubuntu.com/a/1112674/532139 ** Changed in: openssh (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1822370 Title: 19.04 beta openssh-client broken pipe Status in openssh package in Ubuntu: Incomplete Bug description: Upgrade to Xubuntu 19.04 beta from 18.10 openssh-client when trying to ssh into another system, following error: packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Problem is consistent on trying to connect to various systems. Can confirm was able to ssh prior to upgrade and can ssh into these systems from other systems. Can use putty on this system to ssh into these boxes as well. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: openssh-client 1:7.9p1-9 ProcVersionSignature: Ubuntu 5.0.0-8.9-generic 5.0.1 Uname: Linux 5.0.0-8-generic x86_64 ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Mar 29 13:36:38 2019 InstallationDate: Installed on 2018-11-14 (135 days ago) InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: ssh-askpass N/A libpam-ssh N/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.9p1 Ubuntu-9, OpenSSL 1.1.1b 26 Feb 2019 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-03-29 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
