I'm doing remote support for a consultant in a nearby (100 miles) city. I've been using ssh & tunnels to get into his network for years. Last week he had the cable modem replaced with a new 'Technicolor TC8717T'. The FE said it was configured to match the old one. Except that my ssh connection now will not complete.
ssh -v <IP address> shows:
debug1: Connection established
debug1: Local version string SSH-2.0-OpenSSH_7.6
and there it will hang indefinitely. I made a road trip yesterday to resolve this - no luck.
The modem has all firewall options disabled, traffic passes into an old Linksys firewall, this has port 22 forwarded to an internal Linux server. At this server, I run a 'strace' on the ssh daemon and see the inbound connection, the inbound version string, and the daemon returning its version string. This should then move to the authentication phase and send "login". But the client session never receives the server version string.
We reported this problem during the initial modem replacement visit, FE was not comprehending the problem. The next day, we called in again, got another FE visit, he replaced the new modem twice. Problem persists. I had my buddy run a port scan from https://www.grc.com/ - this reports port 22 as open.
Could there be some setting in this specific Technicolor modem that is partially blocking this ssh connection ?? Is there some way to get a tier 2 technician on the phone who understands the basic functionality of ssh ??
You didn't say that port 22 was opened in the Technicolor TC8717t router and that it was also port forwarded inbound and outbound? Port triggering may also be required. just asking.
The cable modem firewall is disabled. The only option to forward port 22 sends it to a bogus 192.168. network that is not part of the internal network. The internal TP-link firewall is set to port forward ports 22 and 222 to internal Linux boxes. This is working since they see the initial ssh handshake packets. The external ssh client also sees the initial connection packets. And this setup worked 2 hours befor the modem was replaced ...
I've now captured packet dumps from the external source and the internal destination.
Source connects, sends version string. Dest sees source version, sends its version string to source. This is never received.
Behaves the same with port 22 and port 222. The modem firewall is disabled and does not appear to be running its own sshd.
Should the cable modem be set to 'bridged mode' ?? I hesitate to experiment since regular outbound internet connectivity is working fine.
If you want assistance and suggestions from the Forum readers you'll have to provide more detailed information about your home LAN and equipment. Since you are running LINUX OS, we will assume you already understand the basic principles of networking.
What are the make and model numbers of the old and new modems? Are you using a router internal to the modem box or a separate external unit? If there is an external router, what is the make & model?
Is your router programmed to perform DHCP? Is it programmed to accept its settings from the Spectrum WAN cable modem? If YES to both, then the modem should not be not causing your problem. If NO, then what other not-yet-identified device is doing DHCP?
What is the IP subnet address and mask the routing device is assigning? (This is the one you said you DON'T want to use) HINT: It would normally be 192.168.1.x using a 255.255.255 mask.
What is the desired IP subnet address and mask for your internal network (home LAN)?? What is your DHCP addressing plan?
Suggestion: Good practice for a home LAN DHCP is to start at 50 and go up to 199. If you need static IP addresses for printers, video cameras and recorders, or other non-roaming devices they would be assigned between 11 and 49, or from 200 to 250. This plan gives you 150 dynamic and 99 static addresses, far more than enough for a home user. Static IP assignments must ALWAYS be on the subnet but outside the DHCP window!