17

I disable the ssh server with systemctl disable ssh then reboot. After reboot, I still can log into the remote server through ssh. I use systemctl status ssh to check the server status and it is inactive.

$ systemctl -a | grep ssh
ssh.service                                               loaded    inactive dead      OpenBSD Secure Shell server
[email protected]:22-192.168.0.104:31079.service        loaded    active   running   OpenBSD Secure Shell server per-connection daemon (192.168.0.104:31079)
system-ssh.slice                                          loaded    active   active    system-ssh.slice
ssh.socket                                                loaded    active   listening OpenBSD Secure Shell server socket
Improve this question
3
  • Could you add the output of systemctl status ssh to your question? Commented Jul 9, 2019 at 15:21
  • It is much like:● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: inactive (dead) since Tue 2019-07-09 23:25:16 CST; 1s ago Commented Jul 9, 2019 at 15:26
  • 1
    Additionally you should block port 22 on the firewall, so that even if the SSH server is running somehow, it won't be accessible from remote. Commented Jul 10, 2019 at 10:51

1 Answer 1

Reset to default
31

The systemd SSH socket is active, and the SSH service is socket-activated. You need to disable the socket as well:

systemctl disable --now ssh.socket

In fact, on my Arch system, the sshd daemon runs only when a new connection comes in. At other times, the only instances of sshd are the child processes forked off to handle those connections.

Also see:

Improve this answer
9
  • 2
    @spender that's Lennart Poettering's official blog, so it's hard to get a 'better' source than that. Not sure why you're getting a warning from Firefox, but I'm not Commented Jul 10, 2019 at 13:50
  • 1
    Ah, you're probably getting a warning about his self-signed certificate. Commented Jul 10, 2019 at 13:54
  • 2
    @spender: Indeed the error message is utterly awful. It should be telling you not to submit private data to the site, not that "hackers can steal your [implied: at-rest] data if you visit the site". It reads like a scareware/fake-AV message which users should be trained to ignore. Commented Jul 10, 2019 at 14:01
  • 2
    Now that Lets Encrypt is so easy to use, Poettering should use it instead of self-signed certificates. :/ Commented Jul 10, 2019 at 14:06
  • 9
    @muru give Poettering a tad bit of time - it takes time to integrate a CA into an init manager.... Commented Jul 10, 2019 at 17:41

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.