2

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
  • What do you do exactly to "allow ssh connection"? Adding another rule might not mean saving that rule across reboots. – Ulrich Schwarz Jul 12 '19 at 10:32
  • Maybe a dumb question but: SSH service is up and running after reboot? – mnille Jul 12 '19 at 10:38
  • @UlrichSchwarz, I did "ufw allow in from any to 192.168.0.120 port 22 proto tcp comment". While I found, I failed to log in, I checked it out with "ufw status". The rule was there. What kind of rules can not be saved across reboot? – codexplorer Jul 12 '19 at 11:04
  • According on the output from /var/log/auth.log, there was debian sshd[577]: error: Bind to port 22 on 192.168.0.120 failed: Cannot assign requested address. debian sshd[577]: fatal: Cannot bind any address.I guessed sshd failed to get the IP while it is starting. Therefore, I add [Unit] Wants=network-online.target After=network.target network-online.target on /etc/systemd/system/sshd.service. But in the end, it doesn't do the trick. – codexplorer Jul 16 '19 at 9:00
3

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

|improve this answer|||||
  • I checked status out for ssh and ufw a lot. Just as I pointed out. Those seem normal. But I still fail to log in via ssh. – codexplorer Jul 12 '19 at 11:25
  • Can you try to connect again and post ssh journal here? If it says connections have been made to it, then ufw works fine. It should say why it was not succesfull. If there is no mention about trying to connect you can try completely disabling ufw or checking if that IP is your device IP. Because you allow it to yourself only if your ssh host IP is the same. – pormulsys Jul 13 '19 at 12:32
  • 1
    Sudo ufw disable – pormulsys Jul 13 '19 at 12:33
  • I have updated the status for sshd. – codexplorer Jul 15 '19 at 4:10
  • Thank you @pormulsys, that was my problem. I had accidentally enabled that – Dara Java Jan 28 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.