Investigating and Solving SSH Issues - ArvanCloud Help Center

SSH is one of the common ways to access the server, this service is pre-installed on all virtual machines with Linux operating system, and the connection information such as username and password is also sent to you via email and pop-up after creating the instance.

If you have encountered problems with SSH to your instance, we suggest that you read this article first, and if you still have problems, read the rest of this article to check and solve the problems.

First step: Make sure that the instance is on

Please go to your user panel and make sure your server is up and running.

Second step: ensuring Internet connection of instance

The easiest and yet most effective way to find out is to use Ping to check the connection to the server, for this please ping your cloud IP address with the command below to make sure it has an internet connection.

ping my_server_ip_address

If the Internet connection was established and the instance was pinged, you may see one of the following messages when you SSH:

ssh: connect to host […] port 22: operation timed out
ssh: connect to host […] port 22: connection refused
Permission denied (publickey)
ssh_exchange_identification: read: Connection reset by peer
REMOTE HOST IDENTIFICATION HAS CHANGED
WARNING: UNPROTECTED PRIVATE KEY FILE!

Connection Timeout

It means that the SSH Client tried to establish a connection with the server and the socket related to SSH, but the server could not respond to the Client within a certain period of time and the connection timed out.

To solve the problem:

Make sure you enter the correct IP address.
Make sure your internet has no problem with the SSH port (usually port 22), for this purpose you can SSH to another server.
Check the server-side SSH service status.

Log in to your instance console through the ArvanCloud panel and look for rules that are Allow for port 22 in the Input Chain with the following command. Note that this command must be run with root access.

iptables -nL

In this section, no rules should deny or close port 22.

Ensuring the status of the SSH service

You can check the status of the service by accessing the instance console in the ArvanCloud panel. To do this, log in to your user panel and find out the status of the service by entering the following command in the desired cloud console:

systemctl status sshd

If the service is not on, run the following command to turn it on and test again:

systemctl start sshd

Checking the status of the SSH service port

This service is activated by default on port 22, but for various security reasons, the default port is changed to other ports. To check the port of this service, use the following command:

grep Port /etc/ssh/sshd_config

If the service is running, you can check its socket status with the following command:

ss-plnt

Checking the firewall status

If you use Firewall:

firewall-cmd --zone=public --add-service=ssh

If you are using UFW (this command must be run with Root access):

sudo ufw allow ssh

If you use IP-Tables (this command must be executed with Root access):

sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW, ESTABLISHED -j ACCEPT

Connection Refused

The Connection Refused message may occur in the following situations:

No service is available on the IP address and port you requested.

Solution (this command must be executed with root access):

sudo apt install openssh-server

The desired service is off and not in Running mode.

solution:

systemctl status sshd

systemctl restart sshd

The firewall of the server or the panel prevents access to the server, which you can configure using this article. If you use Firewall:

firewall-cmd --zone=public --add-service=ssh

If you are using UFW (this command must be executed with Root access):

sudo ufw allow ssh

If you use IP-Tables (this command must be executed with Root access):

sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW, ESTABLISHED -j ACCEPT

Remote host identification has changed

Servers have an identifier called Fingerprint, which is a summary of the server’s public key. When you connect to a server through SSH for the first time, this ID is saved on your laptop or computer to be used for server authentication the next time.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:44m+Q5T0+0bG8XnbEkdusJPuCcYt5OsYt6P8LJXppzQ.
Please contact your system administrator.
Add correct host key in /home/geek/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/geek/.ssh/known_hosts:115
remove with:
ssh-keygen -f "/home/geek/.ssh/known_hosts" -R "37.152.183.81"
ECDSA host key for 37.152.183.81 has changed and you have requested strict checking.
Host key verification failed.

The above message is an example of a situation where the fingerprint of the server has changed and you are trying to connect to the server. This becomes important if you are not sure what network you are using and there is a possibility of a hacker or an intermediary between your connection and the server.

When does Fingerprint change?

1- When you restore the operating system through the panel, the public key of the server will be regenerated and the fingerprint will be changed accordingly.

2- When you remove and reinstall the SSH service from the server.

solution:

After you are sure that you are using a secure network and the correct server IP, you can remove the Fingerprint server from your laptop or computer and connect to the server again.

ssh-keygen -f "/home/geek/.ssh/known_hosts" -R "37.152.183.81"

ssh_exchange_identification : read: Connection reset by peer

This message means that the host (server) suddenly terminates the TCP connection. This disconnection can happen for the following reasons.

The connection is blocked by the Host-Based Access Control List feature.

The existing IDS (intrusion detection systems) may have updated your IP in the firewall list by Fail2ban, DenyHosts and prevented communication.

solution:

For DenyHosts, check the following files on the server and if you find your IP, delete it. This command must be run with root access.

sudo nano /etc/hosts.deny

You can also add your server IP in the file below. This command must be run with root access.

sudo nano /etc/hosts.allow