For website owners, SFTP is one of the ways to transfer files securely in Linux servers.
But at times, due to the misconfiguration of the ssh_config file, firewall blocking port 22 connection and failed ssh service on the server you may get an error like,
ssh: connect to host x.x.x.x port 22: Connection refused
At Bobcares, we help our customers to resolve such SFTP connection refused error in Linux as part of our Server Management Services.
Today, we’ll discuss the top 4 reasons for this error and how our Support Engineers fix them.
SFTP connection refused error – Why & how we fix?
SFTP connection refused is a network error when connecting to the server and you get the error like:
ssh: connect to host myserver port 22: Connection refused
There are several reasons on why the SFTP connection refused error happens and we’ll see how our Support Engineers fix them.
1. Misconfiguration in ssh_config file
In most of the cases, this SFTP connection refused error occurs due to bad settings in the ssh_config file. Recently, one of our customers changed the settings in the ssh_config file and changed the root ownership. And, when he attempted login it resulted in SFTP connection refused error.
For proper working, ChrootDirectory should be owned by root. So, when sshd checks the ChrootDirectory it refuses to allow login and causes a security problem. Thus, results in a connection refused error.
To solve this problem we need to configure OpenSSH that uses SFTP subsystem and chroot.
We executed the steps mentioned below.
1. We edited the /etc/ssh/sshd_config file by adding the following code.
Subsystem sftp internal-sftp Match group sftponly ChrootDirectory /home/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp
2. Then we restarted the service.
2. Firewall blocks port 22
Similarly, SFTP connection refused error happens when the firewall doesn’t allow the connection to port 22. SFTP uses secure port 22 instead of normal FTP port 21. When you want to connect to port 22 it should have an entry in /etc/ssh/sshd_config file and the firewall should allow the connection to port 22. Otherwise, your connection will get refused and results in an error like
"ssh: connect to host my server port 22: Connection refused".
So, to fix this error our Support Engineers perform the necessary steps as shown below.
1. First, we edit /etc/ssh/sshd_config file to listen on port 22.
2. We make sure that there is no # in front of the port number.
3. We run the command netstat | grep 22 to check the port is connected.
4. Next, we allow port 22 in the firewall by executing the command:
ufw allow 22
5. Then we restart the service and that fixes the problem.
3. Improper installation of SSH on the server.
Often SFTP error arises when ssh is not properly installed on the server. So, when you try to connect to SFTP server it always gives error “ssh: connect to host x.x.x.x port 22: Connection refused“.
In Linux servers, we check and make sure that SSH is installed properly by executing the command
dpkg --get-selections | grep ssh
If there is an error, then we install it correctly by running the command:
apt-get install openssh-server
Finally, we restart the service and ensure that the user could connect to SFTP server without any failure.
4. Incorrect port in FTP client
For instance in Filezilla, to securely connect via SFTP you need to provide the hostname and port correctly. However, we’ve seen instances where users use SFTP connection, but fail to provide the correct SFTP port in the FTP client configuration.
Although FTP port is 21 and SFTP port is 22, to connect SFTP server via FTP client correct port should be given in the port field as shown below.
That’s how our Support Engineers fixed the problem and the user could connect to SFTP server without any error.
[Having trouble with SFTP connection refused error? We’ll fix it for you.]
In short, “SFTP connection refused” error happens due to the misconfiguration of the ssh_config file, the firewall blocking port 22 connection and much more. Today, we saw the top 4 reasons for this error and how our Support Engineers fixed them.