Connection Refused

If the host refuses to connect, you will see a message like this:

		

			
				
			
		
		ssh: connect to host 203.0.113.12 port 22: Connection refused
	

This indicates that the host received a connection request from the OpenSSH client but actively rejected it. This is usually related to the SSH server or firewall settings, or specifying the wrong network port for connection.

Below, we have outlined potential causes that could lead to a connection refusal, along with possible solutions to resolve the issue.

The OpenSSH Server Is Not Running on the Host

Possible solution: Ensure that the OpenSSH server is installed and running on the host. Install and start it if necessary.

For a Linux-Based Host:

In the Linux terminal, check the status of the OpenSSH server with the command:

		

			
				
			
		
		sudo systemctl status sshd
	

Depending on the result of the command, the following scenarios are possible:

a. The service is found and its status shows as active (running).

In this case, the OpenSSH server is installed and running. This means that the reason for the connection refusal is due to another issue.

b. The service is found and its status shows as inactive (dead).

In this case, you need to start the OpenSSH server with the command:

		

			
				
			
		
		sudo systemctl start sshd
	

To enable the OpenSSH server to start automatically with the operating system, use the following command:

• For Ubuntu / Debian:

		

			
				
			
		
		sudo systemctl enable ssh
	

• For CentOS, RHEL, Fedora, Rocky, AlmaLinux:

		

			
				
			
		
		sudo systemctl enable sshd
	

c. The service is not found.

In this case, you will see one of the following messages on the screen:

		

			
				
			
		
		Unit sshd.service could not be found.
	

or

		

			
				
			
		
		sshd: unrecognized service
	

In this case, you need to install and start the OpenSSH server. You can learn how to install the OpenSSH server in the instructions "Linux: Installing SSH Server".

For a Windows-Based Host:

Check the status of OpenSSH using PowerShell with the command:

		

			
				
			
		
		Get-Service -Name sshd
	

Depending on the result of the command, the following scenarios are possible:

a. The service is found and its Status shows as Running.
In this case, the OpenSSH server is installed and running. This means that the connection refusal is due to another issue.

b. The service is found and its Status shows as Stopped.
In this situation, you need to start the OpenSSH server with the command:

		

			
				
			
		
		Start-Service -Name sshd
	

To enable the OpenSSH server to start automatically with the operating system, use the command:

		

			
				
			
		
		Set-Service -Name sshd -StartupType Automatic
	

c. The service is not found.

If the following message is displayed on the screen when running the command:

		

			
				
			
		
		Cannot find any service with service name 'sshd'.
	

It means that the service needs to be installed and started. You can learn how to install the OpenSSH server in the instructions “Windows: Using PowerShell to Install OpenSSH Server”.

OpenSSH Server Not Listening on the Correct Port

Possible Solution: Check the configuration of the OpenSSH server and ensure it is set to listen on the port you are trying to connect to. By default, OpenSSH uses TCP port 22. Specify the correct port when connecting, or change the port in the OpenSSH server settings.

For a Linux-Based Host:

a. Open the OpenSSH configuration file on the host.

Use the command:

		

			
				
			
		
		sudo editor /etc/ssh/sshd_config
	

If the command does not work, replace editor with the name of a text editor installed on your system, such as nano or vim.

b. Find the Port parameter in the configuration file.
Use the search function in the editor to find the line starting with Port. The parameter specified on this line determines which port the OpenSSH server uses to connect to the client.

c. Compare the value of the Port parameter.
Ensure that the port number matches the one you are using to connect to the host. The port numbers must match.

If the Port parameter is set to 22 or commented out (begins with the # symbol), it is not necessary to specify the port number when connecting, as port 22 will be used by default.

If the Port parameter is not commented out and differs from 22, make sure to use the correct port when connecting. Specify the port number set in sshd_config using the -p flag in the SSH command:

		

			
				
			
		
		ssh -i <path_to_private_key> <server_username>@<host_IP_address> -p <port_number>
	

For example:

		

			
				
			
		
		ssh -i  d:/test/mykey2 [email protected] -p 64743
	

d. Change the port number.

If necessary, change the Port value in the sshd_config configuration file and save the changes. Changes to the OpenSSH server settings will take effect after restarting the service. You can restart the OpenSSH server with the command:

		

			
				
			
		
		sudo systemctl restart sshd
	

e. Verify security settings.
If you change the port for OpenSSH connections, ensure that the selected port is not blocked by firewalls and security rules on both the client and server sides.

After completing these steps, you should be able to attempt connecting to the OpenSSH server again.

For Windows-Based Host:

a. Open the OpenSSH configuration file on the host.

Open PowerShell as an administrator, then open the OpenSSH configuration file in a text editor:

		

			
				
			
		
		notepad C:\ProgramData\ssh\sshd_config
	

If the command does not work or you prefer another editor, replace notepad with the name of another text editor installed on your system.

b. Find the Port parameter in the configuration file.
Use the search function in the editor to locate the line starting with Port. This parameter specifies which port the OpenSSH server uses to connect to the client.

c. Compare the value of the Port parameter.

Ensure that the port number matches the one you are using to connect to the host. The port numbers must match.

If the Port parameter is set to 22 or commented out (begins with the # symbol), it is not necessary to specify the port number when connecting, as port 22 will be used by default.

If the Port parameter is not commented out and differs from 22, make sure to use the correct port when connecting. Specify the port number set in sshd_config using the -p flag in the SSH command:

		

			
				
			
		
		ssh -i <path_to_private_key> <server_username>@<host_IP_address> -p <port_number>
	

For example:

		

			
				
			
		
		ssh -i d:/test/mykey2 [email protected] -p 64743
	

d. Change the port number.

If necessary, change the Port value in the sshd_config configuration file and save the changes. Then restart the OpenSSH server to apply the changes:

		

			
				
			
		
		Restart-Service -Name sshd
	

e. Verify security settings.

If you change the port for OpenSSH connections, ensure that the selected port is not blocked by firewalls and security rules on both the client and server sides. Check the Windows firewall settings to ensure that the new port is open for incoming connections.

After completing these steps, you should be able to attempt connecting to the OpenSSH server again.

OpenSSH Server Settings Blocking Access

Possible Solution: Ensure that the OpenSSH server settings allow connections and correct any settings that prevent connections.

a. Open the OpenSSH configuration file on the host.

You can open the sshd_config configuration file as follows:

• In a Linux terminal:

		

			
				
			
		
		sudo editor /etc/ssh/sshd_config
	

If the command does not work or you prefer another editor, replace editor with the name of a text editor installed on your system, such as nano or vim.

• In Windows using PowerShell:

Open PowerShell as an administrator, then open the OpenSSH configuration file in a text editor:

		

			
				
			
		
		notepad C:\ProgramData\ssh\sshd_config
	

If the command does not work or you prefer another editor, replace notepad with the name of another text editor installed on your system.

b. Check the parameters and change those preventing the connection.

Note that the OpenSSH server ignores lines that start with the # symbol when loading the configuration. These commented lines do not affect server settings, and the parameters they contain are not applied. If a parameter is commented out, the server will use the default value. To activate a parameter, remove the # symbol at the beginning of the line.

• PubkeyAuthentication:

If PubkeyAuthentication is set to no, it disables key-based authentication. Set it to yes if you need to allow users to connect using keys:

		

			
				
			
		
		PubkeyAuthentication yes
	

• PermitRootLogin:

If you want to connect as the root user, set it to yes:

		

			
				
			
		
		PermitRootLogin yes
	

However, this setting can be insecure. We recommend using a user with sudo privileges instead of root.

• PasswordAuthentication:

If you want to allow password-based connections, set it to yes:

		

			
				
			
		
		PasswordAuthentication yes
	

Ensure that user passwords are strong before enabling password login.

• AllowUsers:

If AllowUsers is used, only the listed users can connect. If your user is not in this list, the connection will be blocked. Add the user you want to allow to connect:

		

			
				
			
		
		AllowUsers user1 user2 myuser2
	

• DenyUsers:

If DenyUsers is used, the listed users cannot connect. Remove the user you want to allow to connect:

		

			
				
			
		
		DenyUsers nosshguy1 badguy2
	

• AllowGroups:

If AllowGroups is used, only the listed groups can connect:

		

			
				
			
		
		AllowGroups sshusers
	

• DenyGroups:

If DenyGroups is used, the listed groups cannot connect. Remove the group you want to allow to connect via SSH:

		

			
				
			
		
		DenyGroups nosshgroup
	

• PermitEmptyPasswords:

If PermitEmptyPasswords is set to no, it prohibits login with an empty password, and users with empty passwords will not be able to connect. Set it to yes if you want to allow users to connect with an empty password:

		

			
				
			
		
		PermitEmptyPasswords yes
	

However, we consider the use of empty passwords to be extremely insecure and only acceptable for research and learning purposes in closed test environments.

• ChallengeResponseAuthentication:

If set to yes, this may require additional authentication measures such as OTP or MFA, which can complicate connections. Set it to no if there are no additional identification requirements, such as OTP or MFA:

		

			
				
			
		
		ChallengeResponseAuthentication no
	

• UsePAM:

Misusing PAM can cause issues, but in most cases, it should be left enabled. Set UsePAM to no only if there are specific reasons to disable it, as it manages many aspects of authentication:

		

			
				
			
		
		UsePAM yes
	

c. Save the changes in the sshd_config file.

d. Restart the service.

To apply the server settings changes, restart the OpenSSH server:

• Linux:

		

			
				
			
		
		sudo systemctl restart sshd
	

• Windows:

		

			
				
			
		
		Restart-Service -Name sshd
	

After restarting the service, attempt to connect to the OpenSSH server again.

Firewall or Network Rules Blocking Connection:

Possible solution: Ensure that your firewall settings allow connections to the host through the specified network port. Make any necessary adjustments to the firewall settings. By default, OpenSSH uses TCP port 22.

Below, we will discuss how to identify and remove SSH connection restrictions, focusing on the most commonly used firewalls that may be pre-installed by default.

UFW (Uncomplicated Firewall) 

UFW is usually pre-installed on Ubuntu distributions. Detailed information about UFW can be found in the "Uncomplicated Firewall Manual".

1. Check the status of UFW.
To get UFW status, use the command:

		

			
				
			
		
		sudo ufw status
	

If the command returns a message like "Command 'ufw' not found..." or "Status: inactive", it indicates that UFW is not installed or inactive. This means it does not impact the connection, and other reasons for the blockage should be investigated.

2. Display UFW rules.
To display the UFW rules, use the command:

		

			
				
			
		
		sudo ufw status numbered
	

3. Check for rules blocking SSH access.

In the displayed list of rules, look for lines marked with DENY or REJECT in the To column that contain the port number used for SSH connections. By default, this is TCP port 22, which may be labeled as OpenSSH or included in a range of ports, such as 19-124.

If no blocking rules are found, this means UFW is not hindering the SSH connection, and the cause of the blockage should be sought elsewhere.

4. Remove rules blocking the connection.

If you find a rule blocking the SSH connection, such as one that blocks only TCP port 22 or the port you are using for the connection, delete it with the following command:

		

			
				
			
		
		sudo ufw delete <rule_number>
	

If the rule blocks multiple ports or a range of ports, do not delete it, as this may negatively affect security. Instead, add a rule that allows access for the specific port, as described in step 5.

5. Add an allow rule.

If there is no rule allowing SSH connections, add one using the following command:

		

			
				
			
		
		sudo ufw insert <position_number> allow from <source> to <destination> port <port_number>
	

• <position_number> – Specifies the position in the rule list where the new rule will be inserted. For example, setting this to 1 places the rule at the top of the list, making it a priority for processing. To be applied, an allow rule must be placed above any deny rule, meaning it should have a lower number in the list.
  
  
• from <source> – Specifies the source of the traffic to which the rule applies. The source can be a specific IP address, a range of IP addresses, or any for all sources.
  
  
• to <destination> – Specifies the destination of the traffic. This can be the server's IP address or any if the rule applies to all destinations.
  
  
• port <port_number> – Specifies the port number to which the rule applies. This can be a specific port (e.g., 22 for SSH) or a range of ports.
  
  

For example:

		

			
				
			
		
		sudo ufw insert 1 allow from any to any port 22
	

This command adds a rule in the first position in the list, giving it the highest priority. The rule allows traffic to port 22 (SSH) from any source to any destination.

If you need to restrict SSH access to a single IP address, the command might look like this:

		

			
				
			
		
		sudo ufw insert 1 allow from 203.0.113.4 to any port 22
	

This command functions similarly to the previous example, except that traffic will only be allowed from the specified IP.

Reload UFW to apply the changes:

		

			
				
			
		
		sudo ufw reload
	

iptables

iptables is a standard part of most Linux distributions, operating at a low level. It is used by other tools, such as UFW and Firewalld, to manage network filtering rules.

Detailed information on working with iptables can be found in the "iptables Manual".

1. List iptables rules.

Open a terminal and run the following command to display the current rules in iptables:

		

			
				
			
		
		sudo iptables -L -n --line-numbers
	

• -L –  List all chains.
  
• -n – Show IP addresses without resolving them to DNS names.
  
• --line-numbers – Display rule numbers.

This command will show which rules are applied to incoming traffic (INPUT), outgoing traffic (OUTPUT), and traffic forwarded through the host (FORWARD).

If the output does not display any rules other than chain headers, as shown here:

		

			
				
			
		
		$ sudo iptables -L -n --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
	

This indicates that iptables is not involved in restricting SSH traffic, and you should look for another cause of the error.

2. Analyze rules for the SSH port.

Review the output of the command to find rules that may be blocking traffic on port 22, the default port used by SSH, or any other port you are trying to connect through. Look for lines containing DROP or REJECT associated with the port used for the SSH connection. If there are no rules restricting SSH traffic, then the cause of the error is not in iptables, and you should look for another reason.

For example, in the following rule configuration:

		

			
				
			
		
		$ sudo iptables -L -v -n --line-numbers
Chain INPUT (policy DROP)
num  pkts bytes target     prot opt in     out     source               destination
1        0     0 DROP       tcp  --  any    any     anywhere             anywhere             multiport dports 20:25
2        0     0 DROP       all  --  any    any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num  pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 627K packets, 73M bytes)
num  pkts bytes target     prot opt in     out     source               destination
	

We see that TCP traffic for ports 20-25, including SSH port 22, is blocked by the DROP rule. There is no ACCEPT rule allowing traffic for port 22.

3. Remove blocking rules.

If you find a rule blocking port 22 or another port you are using, remove it using the following command:

		

			
				
			
		
		sudo iptables -D INPUT <rule_number>
	

• -D –  Indicates that the command should delete a rule from the specified chain.
  

• INPUT – The name of the chain from which the rule should be removed. In this case, the rule is being removed from the INPUT chain, which processes all incoming packets directed to the system.
  

• <rule_number> – The line number of the rule to be deleted from the INPUT chain. Numbering starts at 1, and you can obtain these numbers by running the command iptables -L INPUT --line-numbers to see a list of all rules with their numbers.
  
  

For example:

		

			
				
			
		
		sudo iptables -D INPUT 1
	

This command will delete the first rule in the INPUT chain from iptables. In our example, this rule blocks the group of ports 20-25.

4. Add a rule to allow SSH.

If SSH traffic is blocked by a rule that applies to a group of ports, removing it may pose a security risk to other ports. In this case, add a separate rule allowing incoming SSH traffic. The allow rule should be added directly before the rule that restricts SSH connections. This will allow SSH to work while maintaining restrictions if they are set for other ports.

You can add an allow SSH rule with the following command:

		

			
				
			
		
		sudo iptables -I INPUT <rule_number> -p tcp --dport <port_number> -j ACCEPT
	

• -I INPUT <rule_number> – Inserts a new rule into the INPUT chain before the line with the number specified in the <rule_number> parameter, which processes incoming packets. All other rules with a line number equal to or greater than <rule_number> will increase their number by one.
  
  
• -p tcp – Specifies that the rule applies only to TCP protocol packets.
  
  
• --dport <port_number> – Specifies the destination port to which the rule will apply.
  
  
• -j ACCEPT – Indicates the action to be taken if a packet matches the rule's conditions. In this case, ACCEPT allows packets that meet the specified criteria.
  

For example:

		

			
				
			
		
		sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
	

This command adds a rule in the first line of the INPUT chain, allowing (ACCEPT) the passage of TCP traffic directed to port 22. All other rules in the INPUT chain will have their line numbers increased by one.

5. Verify the changes.

Run the command to list the iptables rules again:

		

			
				
			
		
		sudo iptables -L -n --line-numbers
	

Verify the correctness of the changes and the order of the rules, keeping in mind that the rules are processed sequentially from first to last.

For example, after adding the allow rule to our example from step 2, the rule table will look like this:

		

			
				
			
		
		$ sudo iptables -L -v -n --line-numbers
Chain INPUT (policy DROP)num  pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:22
2        0     0 DROP       tcp  --  any    any     anywhere             anywhere             multiport dports 20:25
3        0     0 DROP       all  --  any    any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num  pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 627K packets, 73M bytes)
num  pkts bytes target     prot opt in     out     source               destination
	

If you have made any mistakes while forming the rules, you can restore unsaved iptables rules with the following commands:

• Ubuntu and Debian:

		

			
				
			
		
		sudo iptables-restore < /etc/iptables/rules.v4
	

• CentOS, RHEL, Fedora, Rocky Linux, AlmaLinux, OpenSUSE:

		

			
				
			
		
		sudo iptables-restore < /etc/sysconfig/iptables
	

• Arch Linux:

		

			
				
			
		
		iptables-restore /etc/iptables/iptables.rules
	

However, the file to save the rules may be in a different location on your system, such as when you use configuration systems or when customizing your system.

If the iptables-persistent package is used on the host, you can restore the rules with:

		

			
				
			
		
		sudo netfilter-persistent reload
	

6. Save the changes.

To make the changes permanent, save the current iptables rules using the following commands:

• Ubuntu and Debian:

		

			
				
			
		
		sudo iptables-save > /etc/iptables/rules.v4
	

• CentOS, RHEL, Fedora, Rocky Linux, AlmaLinux, OpenSUSE:

		

			
				
			
		
		sudo iptables-save > /etc/sysconfig/iptables
	

• Arch Linux:

		

			
				
			
		
		sudo iptables-save -f /etc/iptables/iptables.rules
	

However, the file to save the rules may be in a different location on your system, such as when you use configuration systems or when customizing your system.

If the iptables-persistent package is used on the host, you can save the rules with the following command:

		

			
				
			
		
		sudo netfilter-persistent save
	

7. Attempt to reconnect via SSH.

Network Connection Issues

Network connection issues are highly dependent on the infrastructure, making them difficult to predict and provide universal troubleshooting instructions.

We recommend using the ping and traceroute commands for Linux or tracert for Windows to diagnose the problem, as suggested in the "Connection Timed Out: Network Issues" guide. These commands can help identify the specific part of the network where the issue occurs, allowing you to focus on resolving or bypassing that particular problem.

If you think that the network issue is related to our infrastructure, please submit a ticket to our support team.