Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
Comments on Connection closed by remote host in Putty with hosting provider says that the problem is not on their side
Parent
Connection closed by remote host in Putty with hosting provider says that the problem is not on their side
I use my smartphone as my "router", with dynamic IP addresses, for nearly 3 years and never had any problem SSHing into various shared hosting environments with Putty.
I host my website on a CentOS based shared server environment by Namecheap (Stellar business plan); I have joined there with that plan a few months ago; I normally SSH into that shared hosting environment with an all default Putty 0.70 and the SSH connection is being done with a keyphrased private key and public key.
My problem
In the last few days I have started to experience sudden disconnections from Namecheap's shared server environment with Putty, with the error:
Connection closed by remote host
This problem would normally occur less than five mintues after the SSH connection to that environment:
- I can experience a disconnection while typing commands
- It doesn't matter if commands have been executed or not
- Changing keepalive value from 0 to 1 didn't help
- A similar problem happens with MobaXterm
Contacting Namecheap's support
I have tried to contact the customer support of Namecheap and they say that they have tried to SSH into my account from their computer and didn't encounter any problem.
They suggested to reboot the router (my smartphone) and to try again; I did so by principle but it didn't solve the problem.
Namecheap's staff also asked me to execute various tracert NAMECHEAP_IP commands from CMD spanning hundreds of lines (hence I avoid pasting it here) and after reviewing all the output they said:
The issue seems to be caused by a dynamic IP address. It causes a logout very soon after logging in via SSH.
The dynamic IP can be provided by your current ISP (or it can be a feature of the VPN connection if you use any).
The possible solutions are:
- Contacting your ISP for providing a static IP address or a dynamic IP address, but within the same /24 subnet only.
- Configuring a VPN service with a static IP (or within /24 subnet as well).
Interim note
I have no desire to use a static IP, nor do I want to use a VPN.
My question
How would you suggest to cope with that problem?
In that particular case I can bypass the problem by using GUI tools but I still ask this by principle.
Update
The problem is now solved.
Namecheap's support staff reported:
Our technical department has found that the SSH access was not enabled properly for your hosting account:
the cPanel username was not added correctly in whitelist here: /etc/csf/csf.pignore.nc .
As a result, our firewall noticed that some processes kept being open and closed the connection. The cPanel username is added now.
To me that makes sense because indeed the problem started after changing a Cpanel username.
24/09/20: Since writing the update I didn't have the problem at all.
Post
Fault isolation
You need to take some basic steps to isolate where the problem actually lies.
So far, it seems that you have tried with:
- one means of connecting to the Internet (presumably your cell phone carrier's data plan)
- one ISP (presumably your cell phone carrier)
- one host (your local computer)
- one remote host
- one transport-layer protocol (TCP/IP)
- one application-layer protocol (SSH)
- one client implementation (PuTTY)
- one client operating system (presumably some version of Windows)
- one server implementation (whatever is running on the remote host)
- one server operating system (whatever is running on the remote host)
This is nowhere near enough to determine where the problem might lie, as any one of these could potentially be the culprit.
So, start thinking about how you can change these, one at a time, and see what, if any, change causes the problem to be reduced in magnitude or even go away entirely. Here are some suggestions for how you can approach that; this is not an exhaustive list.
- Do you have any other equipment through which you can connect to the Internet? Can you perhaps try using a different phone? A tech-savvy friend, colleague, neighbor, other family member, or any of a number of other categories of people should be able to help you out with this. If this works, it's something about how you're using your phone as an access point and router.
- Can you try to connect through a different carrier's network? (Or other local upstream provider.) This need not be the same type of upstream connection; if you typically use mobile broadband, for example, don't rule out trying on someone's free WiFi somewhere. If this works, it's likely something that the carrier does that causes your problems.
- Can you try connecting from a different computer? Failing that, can you boot from some kind of live media (for example one of the Linux live distributions) and connect from there? If this works, it's likely something local to your system.
- Can you try connecting to a different host over SSH? There's a fair number of places where you can get free SSH accounts with shell access on systems administered by others; the Tildeverse (try here and here) might be a good place to start looking. Alternatively, just spin up a cheap VPS with some other provider; LowEndBox might be a decent place to start looking for cheap, paid options. If this works, it's likely something about the remote host's configuration.
- Can you try a long-running connection that isn't SSH? For example, do you have the same problem if you connect to your ISP's SMTP server and just let it sit there after the initial SMTP
HELOcommand? Are you able to download a large file (sufficiently large to take those several minutes to download) without the download being interrupted? If this works, it's likely not related to the connection duration as such. - Can you try using some other software? Windows provides a rudimentary telnet client that you can install and use to connect to virtually anything but which of course doesn't speak SSH, or you can try using a different SSH client. If this works, it's likely a problem with either PuTTY's SSH implementation, possibly in interaction with the specific software and settings on the remote end, or some setting within your instance or for your connection.
- Can you try setting your SSH client to some kind of debug or verbose mode? In itself, this won't solve or even work around your problem, but there is a chance that it might help point you toward the culprit or let you rule things out.
- Especially since you have administrative access to the remote host, you can try setting the SSH server to do more verbose logging. This could be both on the firewall level (for example, add rules to log all TCP packets to the appropriate port that have either the SYN or RST bits set, and correlate such log entries with problematic behavior), or at the server application level. Again, this won't directly solve or even work around your problem, but might point you toward the culprit or let you rule things out.
1 comment thread
0 comment threads