In this lecture, we'll continue our discussion on ssh and I'll show you some troubleshooting tips. If 1
you cannot connect to the ssh server, the first thing you should do is to check that the ssh daemon is running 2
on the server machine. 3
Run systemctl status ssh to see it’s status. 4
It's active and running! To start, stop or 5
restarted the service run: systemctl restart ssh to restart the service. 6
systemctl stop ssh to stop the service, now it's stoped, let's see its status, it's inactive and the 7
systemctl start ssh to start the service' now it's are running. 8
If on the client part, you get a message similar to this one when trying to connect and authenticate 9
to the ssh server, then you should double check that you are connecting to the right server. 10
This message can be displayed if, for example, the IP or MAC address of the server have changed. 11
If it's the right server, then you can get rid of the message by removing the server key from the known 12
host's file. 13
The file resides in a hidden directory called .ssh in the user's home directory, on the client 14
machine. 15
This is the known host's file. 16
Go there and remove the server's key. 17
I'm removing the host's key and I'm saving the file. 18
Now, when connecting to the server, the new message about the server's identity will be displayed. 19
This message, accept it if you know it's the right server. 20
If the ssh connection is still not working 21
check if the Port 22, on which the server listens, is open. 22
So from the client scan the Port 22 on the server; use a simple command like telnet or nmap. If the 23
telnet command is not installed, install it by running dnf install telnet 24
Of course, on Ubuntu you should run apt install telnet 25
It was installed and I'm checking the server support, so telnet the IP address of the server 26
and the port; and it's open; it has successfully connected to that port. 27
Or using nmap; I'm installing it: dnf install nmap. 28
Don't forget to run it as root. 29
nmap -p22 and the server's IP address. 30
If it says it's down add the-P and the lowercase n options. 31
And the port 22 is open! If the port is closed, but the ssh daemon is running on the server and I suppose 32
it's running and you've checked that, then you should check if there isn't a firewall on the server 33
that's dropping the packets. 34
The Linux firewall is called net filter ip tables, and you can check if there are any firewall rules 35
by running as root ip tables - the vnL 36
Check if the policy is set to accept and there are no rules that drop the packets. There will be an 37
entire in-depth section on net filter and IP tables later in the course. 38
In this case, the policy is set to accept and there are no firewall rules. 39
If you see any rule or you suspect a firewall issue, then you should know that your Ubuntu distro 40
could have something called ufw, which stands for Uncomplicated Firewall. 41
UFW is a user-friendly front-end for managing iptables firewall rules and its main goal is to make managing 42
firewalls easier or, as its name says, uncomplicated. 43
On Ubuntu UFW should be disabled by default, but you can check its status by running: ufw status 44
verbose. 45
Of course as root! And it's inactive! To enable, respectively disable ufw run as root: ufw enable 46
I have enabled it. 47
I'm disabling it. 48
You can list all application profiles available on your server by running ufw app list. 49
And to configure the ufw firewall to allow incoming ssh connections type the following command ufw 50
allow ssh OK, if there isn't a firewall problem but you still cannot connect, then you can 51
run the ssh client in verbose mode by using the -v option like this. 52
ssh -v the username @ the server's IP address. 53
It causes ssh to print debugging messages about its progress. 54
This is helpful in debugging connection, authentication and configuration problems. 55
Multiple v options increase the verbosity. 56
I'm using double v; it's more verbose. 57
And if the problem still persists, check the server logs. 58
On Ubuntu, the logs are saved in /var/log/auth.log 59
and on Centos the log file is located in /var/log/secure 60
This is the log file of the ssh server on Centos. 61
We'll take a short break, and in the next lecture, I'll show you how to properly secure the ssh server. 62
See you in two seconds.