Hi,
the sshd.service is disabled on my main system (no autostart via systemd when the system boots) if i need it i just start it. But i just had an idea and i am curious if this actually works. I have no idea what systemd is capable of but i know that it brings some interesting stuff like socket activation. So i am wondering if it is possible for systemd to activate the sshd.service when needed? In general, if someone tries to access the pc via ssh? And what about restrictions, like only from the local network or only from a specific ip? Is that possible?
Ordinarily you should leave the service running, that’s the whole purpose and difference between a service and an application.
You then configure your security to allow specific access, like only to remote machines with specific IP addresses, domain or host authentication, certificates, etc.
Nowadays, machines and network connections are likely powerful or capable enough to withstand attacks, but if that concerns you, you can do things like install fail2ban, activate your ssh daemon by email, etc.
But, particularly if you use some strong method of authentication like certificates and have a network adapter that offloads processing from the CPU, that should ordinarily be enough.
TSU
Use firewall to restrict IP that is allowed to connect to port 22.
Apart from the other advices, just think of it. The “system” (whatever software it is) can only detect if some other system’s ssh client wants to connect to the ssh server if it is “listening” on port 22. In other words, there must be a process that registered with the kernel that it wanted to be warned and given control is a connect request arrives for port 22. That procfess is normalt sshd.
Now in earlier Unix/Linux times, when system resources where much more restricted then now, some systems had many processes “listening” on many ports. All those processes where in the sytem, more or less sleeping, but still using resouces (e.g. memory). As a remedy, xinetd was invented. That is a (only one and rather small) deamon that listens om all those ports needed (see xinetd.conf) and when woken up by the kernel because of contact on a posrt, it starts the real sshd/ftpd/rsyncd/whateverd to do the work. That takes of course some extra reaction time to get the connection established, but it is a trade off.
You still can do that. But if you only have sshd to configure in xinetd and taking into account todays amount of memeory, etc. in a system, I wonder if it is worth to do it.
I am not for sure, but as systemd is trying to do a lot of things, it could be that systemd has a mechanism where it can “listen” on a port and then start sshd when needed (same like xinetd). But again some process must “listen”, there is no magic.
Yes, systemd has socket activation, (I recall some distros employing it for cups a few years back for example), however there are discussions around some of the intricacies/issues involved with respect to doing this for sshd. For example
https://bugzilla.redhat.com/show_bug.cgi?id=963268
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867762
https://systemd-devel.freedesktop.narkive.com/QVOYjePz/ssh-socket-activation-was-systemd-unit-files-for-debian-based-systems
FWIW: on 2 VPS’s I have ListenAddress set to some other IP in /etc/ssh/sshd.service. This means I can access those 2 only from that other IP. Last time I tested, this worked as the OP desires.