Can't log in via SSH after reboot!

Question

I turn on firewall with ufw with "systemctl enable ufw; systemctl start ufw" and "ufw enable". Then I set it with "ufw default deny incoming" to stop the incoming traffic. In the meanwhile, I allow ssh connection. So far, everything is all right. I am sure I can log in the server via ssh. But after I reboot, I can't log in via ssh anymore. I check ufw out as below

#ufw status
Status: active

To                         Action      From
--                         ------      ----
192.168.0.120 22/tcp       ALLOW       Anywhere

# systemctl status ufw
● ufw.service - Uncomplicated firewall
Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor
preset: enabled)
Active: active (exited) since Fri 2019-07-12 17:43:24 CST; 2min 36s ago
Docs: man:ufw(8)
Process: 241 ExecStart=/lib/ufw/ufw-init start quiet (code=exited,
status=0/SUCCESS)
Main PID: 241 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/ufw.service

ufw is enabled for sure. After that, I allow ssh connection again just like I did first time. Then I can log in vis ssh again. I don't think it's normal. But I don't know how to fix it?
[Update]

#systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor
preset: enabled)
Active: failed (Result: exit-code) since Mon 2019-07-15 11:53:22
CST; 2min 19s ago
Process: 603 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255)
Process: 537 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 603 (code=exited, status=255)

Jul 15 11:53:22 debian systemd[1]: Starting OpenBSD Secure Shell server...
Jul 15 11:53:22 debian systemd[1]: ssh.service: Main process exited,
code=exited, status=255/n/a
Jul 15 11:53:22 debian systemd[1]: Failed to start OpenBSD Secure Shell server.
Jul 15 11:53:22 debian systemd[1]: ssh.service: Unit entered failed state.
Jul 15 11:53:22 debian systemd[1]: ssh.service: Failed with result 'exit-code'

#/etc/ssh/sshd_config:
Port 22
ListenAddress 192.168.0.120
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin yes
AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
AllowUsers arcstor root
Compression yes
PubkeyAuthentication no
PasswordAuthentication yes

Answer 1

Check ssh status:

# systemctl status ssh

If the service is "disabled":

# systemctl enable ssh #enable run on startup
# systemctl start ssh #start it right now

If you get some error on why it is not starting up:

# journalctl -u ssh

There you should see why it is not being started and act accordingly.

You can also try setting ufw to allow ssh from all addresses:

# ufw enable ssh

EDIT: Response to a comment:

It is failing to start, but I cannot see why. Is 192.168.0.120 the IP address of the device you want to SSH TO and is it possible it was changed because of DHCP? You can check with "ip address". If your ssh server has only 1 IP this setting isn't really needed and in case of changing IP, will cause problems.

I would recommend removing the package and reinstalling it, probably the fastest way to get default working environment. But when you remove package you must remove configs too, on Ubuntu (and other Debian derivatives) you add "--purge" to "apt remove ssh", try finding something similar for your distribution. After such remove/reinstall you should not have any old configs in it and you can add your preferences again.

 $ sudo apt remove --purge ssh

If you want to list IP addresses you want to connect FROM (not TO), the solution is in the link bellow. It allows you to allow certain IP to connect, others not (ufw is just a wrapper of iptables, thus the command will have the same effect as ufw commands). If you add TO IP, then that IP must be the IP of your host SSH device, in short: the one we are trying to fix, again if you only have 1 IP I don't see the point, either you allow connection or not. Maybe if you used more IP addresses on the SSH server and you would like to allow some to accept SSH connections and others not.

Limit SSH access to specific clients by IP address