FS#62553 - openssh client broken, cannot connect to remote servers

Attached to Project: Arch Linux
Opened by Sebi (s2020) - Sunday, 05 May 2019, 22:39 GMT
Last edited by Gaetan Bisson (vesath) - Monday, 16 September 2019, 18:26 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
If you try to connect to a remote server, ssh crashes after successful login to the remote server.

Additional info:
* Version: 8.0p1-1
* Logs:
debug1: Trying private key: /home/sebi/.ssh/id_dsa
debug1: Trying private key: /home/sebi/.ssh/id_ecdsa
debug1: Trying private key: /home/sebi/.ssh/id_ed25519
debug1: Trying private key: /home/sebi/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to xxx ([xx.xxx.xxx.xxx]: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
client_loop: send disconnect: Broken pipe <- this is displayed before the ssh client crashes.

Steps to reproduce:
1. connect to your favourite server with "ssh user@server"
2. try to login with your credentials

=> crash after successful login.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Monday, 16 September 2019, 18:26 GMT
Reason for closing:  Upstream
Comment by Antonio Rojas (arojas) - Sunday, 05 May 2019, 22:56 GMT
Please post a backtrace of the crash
Comment by Yishen Miao (mys_721tx) - Monday, 06 May 2019, 06:51 GMT
The upstream mail list has a related report <http://lists.mindrot.org/pipermail/openssh-unix-dev/2019-April/037698.html>. I was also able to reproduce the problem on my box inside VMware Fusion. However, the problem is resolved with `-o IPQoS=throughput`.
Comment by Freya Gentz (zegentz) - Tuesday, 07 May 2019, 01:08 GMT
I can reproduce this on my RPI2 (Arch Linux Arm) which is SSHing into my main rig (Arch Linux, w/testing). Happens after 2 minutes of idling. Fixed by `-o IPQoS=throughput`. This is not just limited to VMs.
Comment by Freya Gentz (zegentz) - Tuesday, 07 May 2019, 01:11 GMT
Actually scratch that. `-o IPQoS=throughput` did not fix it, nor does `-o IPQoS=none`.
Comment by Sebi (s2020) - Tuesday, 21 May 2019, 22:32 GMT
@Antonio Rojas
I have to correct myself. It hasn't crashed in the sense that it caused a stack fault or something like that. It just exited with no more info than already given in the debug log.
Comment by Gaetan Bisson (vesath) - Wednesday, 22 May 2019, 20:13 GMT
Thanks for your report but please do contribute to the upstream discussion if your problem has yet to be fixed. Or perhaps create a new discussion if you believe it is a different problem. Once a fix is published by upstream I will make sure it lands in Arch as soon as possible. Cheers.

Loading...