Connecting to a Server using SSH¶

In this article

Connecting to a server via SSH from Linux

Connecting to a server via SSH from Windows

SSH Connection Troubleshooting

Connecting to a server via SSH from Linux¶

To connect to your server via SSH from Linux, follow these steps:

Check for the server's IP address. Make sure you know the server's IP address. If you don't know it, you can find it in the Invapi Control Panel.
Install an SSH client (if necessary). An SSH client is usually already installed by default on most Linux distributions. To check this, open a terminal and run the command:
```
ssh --version
```
If the client is installed, you will see the program version.

If the SSH client is not installed, install it using your distribution's package manager:
- For Ubuntu/Debian:
```
sudo apt update
sudo apt install openssh-client
```
- For CentOS/RHEL:
```
sudo yum install openssh-clients
```
Connect to the server. Open a terminal and enter the following command:
```
ssh <username>@<server IP address>
```
For example:
```
ssh [email protected]
```
Enter your password. After connecting, the system will prompt you to enter the password for the specified user. The server's login and password are sent to you via email when it is delivered.

Connecting to a server via SSH from Windows¶

Check for the server's IP address. Make sure you know the server's IP address. If you don't, you can find it in the Invapi Control Panel on the HOSTKEY.com website at https://invapi.hostkey.com.
In Windows 11, there are several ways to connect to a server via SSH:

Using OpenSSH (built-in application)¶

Starting with the October 2018 Update of Windows 10, the SSH client is included by default. To check this, run PowerShell and execute:
```
ssh
```
If the client is installed, you will see output options for its use.

If the SSH client is not installed, enable it through Settings:

1. Go to **Settings** > **System** > **Additional components**.

2. Find `OpenSSH Client` and install it.

Connect to the server. Open PowerShell and enter the following command:
```
ssh <username>@<server IP address>
```
For example:
```
ssh root@192.168.0.100
```
Enter your password. After connecting, the system will prompt you to enter the password for the specified user. The server's login and password are sent to you via email when it is delivered.

Using PuTTY (alternative client):¶

Download PuTTY from the official website https://www.putty.org.
Launch PuTTY and enter the server's IP address in the field "Host Name (or IP address)".
Specify the connection type as SSH and click Open.
Connect to the server:
- Enter the server's IP address in the field Host Name (or IP address).
- Specify port 22 for SSH if it has been changed.
- Click Open. In the window that opens, enter your username and password.
Enter your password. After connecting, the system will prompt you to enter the password for the specified user. The server's login and password are sent to you via email when it is delivered.

Note

It is recommended to use SSH keys instead of passwords for more secure authentication. Instructions for setting up SSH keys can be found in your distribution's documentation or in our guide.
If you receive an error Connection refused, make sure that the SSH server is running on the target server and port 22 is open in the firewall.

SSH Connection Troubleshooting¶

By performing this diagnostic, you will be able to determine where the SSH connection is being lost: on your side, on the server (sshd, firewall, settings), or on your provider's side. Perform the steps in order and save the command output—it will be required by support.

Attention

In the commands below, replace SERVER_IP with your server's IP address. Commands on the server must be executed as root or via sudo. If SSH is unavailable to the server, log in via the web console (VNC/KVM) in the hosting panel.

Step 1. Check from your computer¶

The goal is to determine if the server is reachable and if port 22 is responding. These commands are executed on the computer you are connecting from.

Server network availability
```
ping -c 4 SERVER_IP
```
No response does not necessarily mean an error: ICMP is often blocked by a firewall. The main check is the next step.

Is port 22 responding?

nc -vz -w 5 SERVER_IP 22

# if nc is not installed:
timeout 5 bash -c '</dev/tcp/SERVER_IP/22' && echo OPEN || echo CLOSED

Result	Meaning
succeeded / open	Port is open, network is fine—the issue is with authentication or sshd settings (Step 4)
Connection refused	Server is reachable, but nothing is listening on port 22 or the firewall is sending a REJECT (Steps 2–3)
timed out	Packets are being lost: firewall DROP, provider filter, or a block along the route (Steps 3 and 5)
No route to host	No route to the server or the server is powered off (check its status in the panel)

Precise check via nmap

Shows the port status and what is running on it. Installation: sudo apt install nmap or sudo dnf install nmap.

# port 22 status and SSH server version
sudo nmap -Pn -sV -p 22 SERVER_IP

# with reason for status and route to the server
sudo nmap -Pn -p 22 --reason --traceroute SERVER_IP

# compare 22 with other ports (filters only 22 or everything?)
sudo nmap -Pn -p 22,80,443,2222 --reason SERVER_IP

# SSH algorithms – if the script runs, the key exchange is working
nmap -Pn -p 22 --script ssh2-enum-algos SERVER_IP

-Pn is required so that nmap does not assume the server is down if ping is blocked.

nmap Status	Meaning
open (reason syn-ack)	Port is open, sshd is responding; `-sV` should show an OpenSSH version
closed (reason reset)	Server is reachable, but sshd is not listening on the port (Step 2)
filtered (reason no-response)	Packets are being lost: firewall DROP or a block along the route (Steps 3 and 5)
filtered (reason admin-prohibited)	Firewall is responding with a rejection—REJECT rule on the server or at the provider (Step 3)
open, but `-sV` shows no version or tcpwrapped	TCP connection passes, but the SSH banner is not received—TCP Wrappers, fail2ban, or DPI (Steps 4–5)

If --traceroute responses drop off at your provider's nodes while 80/443 remain open, this is a strong sign of filtering specifically on port 22. Save the output for support: add -oN nmap.txt to the command.

Detailed connection log

Shows at which stage the connection drops:
```
ssh -vvv -o ConnectTimeout=10 user@SERVER_IP 2>&1 | tee ssh_debug.log
```
- Hanging at Connecting to — network issue.
- Disconnection after Connection established (e.g., at SSH2_MSG_KEXINIT or Connection reset by peer) — typical sign of DPI filtering or fail2ban.
- Permission denied — network is fine, but the key or password is incorrect.
Route to the server specifically via TCP port 22
```
sudo traceroute -T -p 22 SERVER_IP

# or a summary of packet loss:
sudo mtr -T -P 22 -r -c 50 SERVER_IP > mtr.txt
```
Observe at which node the responses stop. A disconnection within your provider's network indicates filtering along the route rather than an issue with the server.
Rule out your own network

Repeat Step 2 using a mobile hotspot and check if outbound port 22 is blocked on your work/corporate firewall.

Step 2. Is the SSH server running?¶

Performed on the server (via the hosting web console). In Debian/Ubuntu, the service is named ssh; in CentOS/RHEL/Alma/Rocky, it is sshd.

Service status
```
systemctl status ssh || systemctl status sshd
```
It should be active (running). If it is inactive or failed, start the service and enable it to start on boot:
```
sudo systemctl enable --now ssh   # or sshd
```
If the service fails to start, the reason will be listed in the logs.

Package not installed

Error Unit ssh.service could not be found:

sudo apt install openssh-server   # Debian/Ubuntu
sudo dnf install openssh-server   # CentOS/RHEL/Alma/Rocky

Which port and address is sshd listening on?

sudo ss -tlnp | grep -E 'sshd|:22'

Output	Meaning
`0.0.0.0:22` or `[::]:22`	Everything is fine; listening on all interfaces
`127.0.0.1:22`	Listening only locally — fix `ListenAddress` (Step 4)
Other port, e.g., `:2222`	Connect using that port: `ssh -p 2222 user@SERVER_IP`
Empty	sshd is not running or could not bind to the port — see logs above

Ubuntu 22.10+ and socket activation

In these versions, the port is defined in ssh.socket as well as sshd_config. To check:
```
systemctl status ssh.socket
```
After changing the port, run:
```
sudo systemctl daemon-reload && sudo systemctl restart ssh.socket
```
Testing from the server itself
```
ssh -v localhost
```
If it works locally but not from the outside, the issue lies with the firewall or the network (Steps 3 and 5).

Step 3. Server Firewall¶

Typically, one of three firewalls is running on the server: ufw (Ubuntu), firewalld (CentOS/RHEL), or raw iptables/nftables. Check all three—sometimes two are active simultaneously.

Attention

If you are currently connected via SSH and not through the web console, first allow port 22, and only then enable or restart the firewall—otherwise, you will lose access.

ufw

sudo ufw status verbose

# if 22/tcp is not in the ALLOW list:
sudo ufw allow 22/tcp

firewalld

sudo firewall-cmd --state
sudo firewall-cmd --list-all

# if ssh is not in services:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

iptables / nftables

sudo iptables -L INPUT -n -v --line-numbers
sudo nft list ruleset

Look for rules with dpt:22 or tcp dport 22 and the action DROP / REJECT, as well as a policy DROP without an allow rule for port 22. Pay attention to rules restricting access by source (-s) or by country (using geoip modules or ipset lists): because of these, the server might be accessible from everywhere except your country.

To temporarily allow SSH at the beginning of the chain (until reboot):

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

If the connection works after this, the cause has been found; save the rule via your firewall (ufw/firewalld) or using iptables-save.

Step 4. sshd Settings and Security Tools¶

If the port is open but the connection is dropped or authentication fails, check your configuration and any blocks.

Final sshd configuration

Taking into account files in sshd_config.d/:
```
sudo sshd -T | grep -Ei '^(port|listenaddress|permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|allowgroups|denyusers|maxstartups)'
```
Check:
- port 22;
- listenaddress 0.0.0.0 (not 127.0.0.1);
- that your user is in allowusers, if that parameter is set;
- permitrootlogin and passwordauthentication — ensure they are set to your required values.
Syntax check before restarting

After any modification to /etc/ssh/sshd_config, always check the syntax before restarting:
```
sudo sshd -t && sudo systemctl restart ssh   # or sshd
```
fail2ban

It may have blocked your IP after failed login attempts:
```
sudo fail2ban-client status sshd

# to unban your IP:
sudo fail2ban-client set sshd unbanip YOUR_IP
```
You can find your external IP from your client machine using the command curl -4 ifconfig.me. Similarly, check CrowdSec or sshguard if they are installed.
TCP Wrappers (on older systems)
```
cat /etc/hosts.allow /etc/hosts.deny 2>/dev/null
```
A line like sshd: ALL in hosts.deny blocks everyone not specified in hosts.allow.
What the server sees during your connection attempt

Run this on the server, then attempt to connect from the client:
```
sudo journalctl -u ssh -u sshd -f

# in a second window – check if packets are reaching the server:
sudo tcpdump -ni any tcp port 22 and host YOUR_IP
```
- If tcpdump shows nothing—packets are not reaching the server; the issue is in the network path (Step 5).
- If packets arrive but the sshd log is empty—they are being dropped by the server firewall (Step 3).

Step 5. Unavailability specifically from your country¶

If everything is fine on the server (Steps 2–4) but packets from your country are not arriving, you need to compare port availability from your country versus other countries.

Check the port from external locations

Use the check-host.net service → TCP port tab, enter SERVER_IP:22. Check the results for your country and international nodes.

From your country	From other countries	Conclusion
Fails	Works	Routing filtering from your country or geoblocking on the server/host side
Fails	Fails	Problem on the server — return to Steps 2–4
Works	Works	Problem with your ISP or local network

Compare providers within your country

Home internet and mobile operators often behave differently. If it works through one but not the other, the block is on the specific provider's side.
Check if it is specifically port 22 that is affected

Temporarily add a second port to /etc/ssh/sshd_config on the server (the original Port 22 line remains):
```
Port 22
Port 2222
```
Allow 2222/tcp in your firewall (Step 3), then run:
```
sudo sshd -t && sudo systemctl restart ssh
```
And connect:
```
ssh -p 2222 user@SERVER_IP
```
On SELinux systems (CentOS/RHEL), perform this additional step:
```
sudo semanage port -a -t ssh_port_t -p tcp 2222
```
If it works on 2222 but not on 22, the standard port is being filtered.
Signs of DPI filtering

The TCP connection is established (nc shows open), but ssh -vvv terminates during the key exchange; or the connection works for a few seconds and then hangs. In this case, the server settings are not the cause — please send the logs to support.

What to include in your support message¶

If the problem is not resolved, send us the following — this will reduce diagnostic time:

Server IP and your public IP (curl -4 ifconfig.me), city, and ISP;
nmap.txt file and the result of nc -vz -w 5 SERVER_IP 22;
ssh_debug.log file (Step 1, item 4);
mtr.txt file or the output of traceroute -T -p 22;
Server output: systemctl status ssh, ss -tlnp | grep :22, and firewall rules (ufw status verbose / firewall-cmd --list-all / iptables -L INPUT -n -v);
A link to the TCP port check result from check-host.net;
Whether the connection works via mobile internet and on port 2222 (if you tested it).

Attention

Do not send passwords or private keys. The ssh -vvv log does not contain them, but please review it before sending.

2026-10-30