1

first post in this community!

I'm having a couple issues with SSH on a newly installed Ubuntu 19.10 desktop:

When SSHing to this machine on my local network I occasionally have hangs in responsiveness from the terminal. Eg. I'll be typing and it'll stop, then catch up after 5-10 seconds

When remote SSHing from work, I have been getting 'client_loop: send disconnect: Broken pipe' errors consistently. Sometimes immediately after logging in, no delay at all. Sometimes it does this after connecting, doing some work, then sitting idle (like going for a 10 min break) then it dies as soon as I start typing again

I've tried editing the sshd_config and my local .ssh/config file for TCPKeepAlive, Client/Server AliveInterval & AliveCountMax and nothing seems to help.

Current remote .ssh/config:

Host home

User sean

HostName xxxxxxx

IdentityFile /home/sean/.ssh/home.rsa

Port xxxx

ServerAliveInterval 30

ServerAliveCountMax 1200

ForwardX11 yes

Compression yes

IPQoS throughput

TCPKeepAlive yes

I do have some port bindings as well, if that's relevant. IPQoS was a setting I turned on from a different forum post, but it didn't help. Here's the host sshd_config:

TCPKeepAlive yes

PermitUserEnvironment no

Compression delayed

ClientAliveInterval 60

I have also changed the listening port and disabled password auth, but that's it.

Further, if I change my .ssh/config to something like ServerAliveCountMax 0 and ServerAliveInterval 30, it'll timeout instead with 'Timeout, server xxx not responding.'

I was using a different server at home previously which worked for several months, then had the broken pipe issue. I thought the new server would help, but they both have this issue. Nothing on my network has changed as far as I know. Could my work network be causing this? I don't connect to these from anywhere other than home/work so I don't know if the behavior happens from like Starbucks or somewhere.

Any ideas?

Edit: I tried arp-scan to see if I happen to have two machines on the network with the same IP, it returned only one. Further both machines were static IPs below the DHCP range, so it shouldn't be possible to have two using the same IP since I'm setting them.

Edit2: I tried Putty from windows as a test and I'm not seeing this happen there. I have some port forwarding happening, but not as many. Further, the Keepalives is set to 60 - the default, I think? Does this maybe imply I should have either Client/Server keepalives set, but not both?

Edit3: Putting this here as it's too long for a comment: Well, it happened, it just took a lot longer than normal - it also disconnected on the Putty side at the same time. Here's the last few lines of -vvv output:

debug3: receive packet: type 96 debug2: channel 60: rcvd eof debug2: channel 60: output open -> drain debug2: channel 60: obuf empty debug2: channel 60: chan_shutdown_write (i3 o1 sock 66 wfd 66 efd -1 [closed]) debug2: channel 60: output drain -> closed debug3: receive packet: type 97 debug2: channel 60: rcvd close debug3: channel 55: will not send data after close debug3: channel 58: will not send data after close debug3: channel 59: will not send data after close debug3: channel 60: will not send data after close debug3: channel 61: will not send data after close debug2: channel 55: send close

** #14 direct-tcpip: listening port 8123 for fonts.googleapis.com port 443, connect from 127.0.0.1 port 42686 to 127.0.0.1 port 8123 (t4 r13 i0 debug2: channel 60: send close debug3: send packet: type 97 debug2: channel 60: is dead debug2: channel 60: garbage collecting debug1: channel 60: free: direct-tcpip: listening port 8123 for ui.crackedcdn.com port 80, connect from 127.0.0.1 port 42866 to 127.0.0.1 port 8123, nchannels 34

** debug2: channel 29: read<=0 rfd 35 len 0 debug2: channel 29: read failed debug2: channel 29: chan_shutdown_read (i0 o0 sock 35 wfd 35 efd -1 [closed]) debug2: channel 29: input open -> drain debug2: channel 29: ibuf empty debug2: channel 29: send eof debug3: send packet: type 96 debug2: channel 29: input drain -> closed debug2: channel 25: read<=0 rfd 31 len 0 debug2: channel 25: read failed debug2: channel 25: chan_shutdown_read (i0 o0 sock 31 wfd 31 efd -1 [closed]) debug2: channel 25: input open -> drain debug2: channel 25: ibuf empty debug2: channel 25: send eof debug3: send packet: type 96 debug2: channel 25: input drain -> closed debug3: send packet: type 1 client_loop: send disconnect: Broken pipe

One of my forwarded ports I'm using as a proxy since some of my email is blocked at work. So it died, but why?

Improve this question
16
  • It looks like you've quite a mess there. I'd purge ssh, remove any user ssh config files and then try again with a completely clean and simple install. Set your router to forward port 22 to your machine and try again. Then add in your special security features one by one. – Stephen Boston Jan 3 '20 at 12:52
  • It is, yes. Interestingly, the 'hang' issue I mentioned was on completely stock settings and without the customizations I wasn't able to login from work where the broken pipe issue happens. I have turned off most of the port forwarding on the client side, but it still behaves the same.In case it matters, someone else asked my MTU and Routes config - they're both automatic on client and server. – seanferd Jan 3 '20 at 13:48
  • Oh dear. Have you tried ssh -vvv for verbose tracing of the ssh transaction? – Stephen Boston Jan 3 '20 at 14:10
  • 1
    That seems to be the case. I left it running overnight and it did get a 'broken pipe' at some point. I've remounted and reconnected and it seems fine again. If nothing else, it's much more usable than before - sometimes those broken pipes would happen seconds after logging in - I was actually able to get a few things done yesterday! – seanferd Jan 8 '20 at 13:45
  • 1
    This will probably be my last update on this. I used the sshfs 'trick' all last week to good results, though I still don't know why. I came in fresh Monday morning and forgot that I needed to use the trick to get ssh to work and accidentally found out that the problem has completely gone away. I left a session open last night and it's still open today, in fact I haven't seen a broken pipe at all this week knock on wood. I have no idea what changed, if anything. Further I'm back to using my original ssh config in its entirety, including all the port forwarding. I have no explanation – seanferd Jan 14 '20 at 13:42
0

This won't solve any underlying connectivity issues, but mosh will make your connection feel responsive.

From the web page:

Mosh is a remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.

Mosh is a replacement for interactive SSH terminals. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Mosh is free software, available for GNU/Linux, BSD, macOS, Solaris, Android, Chrome, and iOS.

Simply install on both client and server:

sudo apt install mosh

and then use mosh instead of ssh to connect:

mosh user@server
Improve this answer
1
  • I've seen that mentioned a few times and at this point I think I'll have to try it out. I've been trying to migrate databases from the old machine to this one and getting nowhere because it keeps dying. What's strange is that it worked fine until a month or so ago, around that time I had added in the port bindings to my client config file, but removing them now doesn't seem to help. – seanferd Jan 3 '20 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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