 |
It's hard to tell with a description this brief, but this is almost certainly related to a known VMware bug[1]. If the reporter could confirm that this was observed in a VMware VM with NAT, that would be very helpful. That said, I was able to successfully reproduce the issue with those assumptions. In short, as of OpenSSH 7.8 the default IPQoS values have changed to DSCP AF21 for interactive traffic and CS1 for bulk traffic[2][3]. vmnat does not support these, and breaks the connection immediately after ssh auth completes. As far as I can tell, there are four possible solutions: 1) Wait for VMware to fix vmnat (no sign of this happening in sight, this bug has been present for months) 2) Patch OpenSSH to revert the changes in [3] while waiting for 1) to happen. 3) Alter /etc/ssh/ssh_config to override the default QoS settings. "IPQoS throughput" will do the trick, and the QoS implications are minor. 4) Downgrade OpenSSH (which sounds like a bad idea, but it technically resolves the issue. It's what Ubuntu are doing, so it must be good, right?) [1] - https://communities.vmware.com/thread/590825 [2] - https://www.openssh.com/txt/release-7.8 [3] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c.diff?r1=1.283&r2=1.284&f=h |
|
|
This was using vmWare Fusion 8.5.10 on a Mac with a Kali VM with a NAT connection. I can confirm that using "IPQoS=throughput" on the command line when using SSH works. Thanks |
- Anonymous