Pour ma part, je laisse l'écoute sur le port 22 pour mon RPI mais par contre j'ouvre un port supérieur à 10 000 que je redirige vers le port 22.

Mais en effet après réflexion, un pirate pourrait pénétrer sur le réseau local, et à partir du réseau local, il pourrait faire un scan. Je n'avais pas pensé à cette éventualité. C'est pourquoi je change uniquement le port extérieur sur mon ip public.

Bien entendu, je fais une connexion par clef/privé uniquement + connexion par un compte utilisateur normal (non root) uniquement .

Je partage, par pure logique, cette pensée qui me pénètre un peu plus, à chaque fois que l'adversité m'inflige l'utilisation de systemd.
Sérieux, je vous aime d'amour, tous, mais comment faites vous pour vous laisser infliger ça ?

Là où je te rejoins, c'est que dans le passé, en bricolant quelques fichiers rc* et quelques fichiers de configuration, tu arrivais facilement à modifier une configuration ... sans avoir besoin d'une connexion Internet pour trouver des tutoriels, FAQ, manuels en ligne, ChatGPT ou autres.
Il me semble que c'est plus simple qu'évoqué dans ce fil, sur d'autres systèmes utilisant systemd : je l'ai indiqué ici (mais sans être allé plus loin qu'un test de base).
Ah, au fait, il faut aussi maîtriser SELinux, tu ne parles pas de cet autre empêcheur de tourner en rond.

Pas besoin de débattre sur systemd:

- Sans systemd:
sed -i 's|^Port 22|Port 2222|g' /etc/ssh/sshd_config
/etc/init.d/sshd restart
- Avec systemd:
4 pages sur ce forum....
Je ne trouve pas normal de devoir passer par la configuration de systemd pour configurer un service donné, et encore plus pour un service dont le code est orienté sécurité voir audité car systemd ne l'est clairement pas.

Sinon pour être constructif, le changement de port pour éviter les scans ou l'utilisation de fail2ban/denyhosts/sshguard ne servent pas à grand chose si ce n'est alléger les logs.
En effet les scans et notamment les attaques par dictionnaire sur SSH repose sur le fait que par défaut, sshd demande  un mot de passe si aucune clé ssh présenté ne convient.

Pour sécuriser proprement un service SSH, il faut autoriser uniquement l'autentification par clefs et interdire toute autentification par mot de passe.
C'est la directive AuthenticationMethods qui liste l'ordre et les méthode d'authentification qui peuvent être utilisés à la connexion et qui par defaut propose le login par mot de passe après les méthodes par clés.

Exemple:

/etc/ssh/sshd_config

---

PermitRootLogin prohibit-password
AuthorizedKeysFile  .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no ( ChallengeResponseAuthentication no  #si vieille version d'openssh)

AuthenticationMethods publickey
AllowUsers user1 user2
AllowUsers user3 user4
...
Avec une telle configuration, plus de problème avec les attaques par dictionnaires sur le mot de passe car elles ne peuvent plus fonctionner.
De plus authoriser les utilisateurs explicitement par la directive AllowUsers évite à un attaquant d'utiliser un dictionnaire afin de deviner si un compte existe.
Si vous utilisez une taille de clé assez conséquente, une attaque par dictionnaire sur la clé elle même devrait prendre quelque siècles au mieux.
Je suggère une taille de clé de 8192 bits pour des clé de type RSA actuellement.

Si la pollution des logs ssh vous pose un problème, c'est au niveau du service de gestion des logs qu'il faut agir: syslog-g ou rsyslog voir systemd qui fait tout sauf le café dont vous avez besoin pour le configurer.

y'a de la confusion la...

Le point de départ c'est l'activation sur première connexion (socket-activated service), ...

Titre du sujet: Changer le port d'écoute de SSH, sur Ubuntu 24.04 LTS
Introduction: Changement de port de SSH, pour limiter d'être la cible des attaques sur le port 22 est une bonne pratique (le port TCP 22 est le port par défaut sur lequel écoute SSH).

Ma réponse parle de comment se protéger des attaques sur le port 22, port défaut du service SSH donc parfaitement dans le sujet.

Quant à l'activation à la première connection, ce n'est en aucun cas une feature inédite de systemd car c'est exactement ce que permettait de faire auparavent tcpd (TCP Wrappers), ca a toujours été déconseillé pour le service SSH car parfaitement inutile (sauf pour augmenter la surface d'attaque). Ca n'apporte aucune sécurité de plus et en réalité c'est même plutôt stupide quand tu sais que sshd ne démarre pas pour des raisons de sécurité à la moindre erreur de configuration ou de permissions sur les fichiers du services /etc/ssh/* ou les autres fichiers utilisateurs tel que les clefs privée/publique ssh, authorized_keys, les repertoires .ssh; du coup démarrer le service qu'à la demande via l'activation à la première connection fait que si tu n'as pas testé une connexion SSH après modification de quoi que ce soit (service ou conf user) et si il y a la moindre erreur, ton service SSH ne demarrera pas du tout et tu n'accèderas pas à ta machine a distance tout court.
En usage classique, tu es obligé de redemarrer ton service pour prendre en compte la moindre modification et tu es averti qu'il y a un problème quelque part tout de suite et pas le jour où tu en as besoin. D'ailleurs le pire cas d'usage de cette "feature" serait sur un serveur...

SSH reste le service essentiel pour de l'administration de serveurs à distance aujourd'hui et je ne vois pas vraiment le rapport avec du LAMP (en quoi d'ailleurs ce serait antique à l'heure où cela représente la majorité des sites web).
SSH reste donc un service critique pour l'accès à distance, notamment en contexte de production.

Systemd, à l'instar de quasi tous les autres systèmes de gestion des services ayant existé et existant sur linux,  ajoute des abstractions supplémentaires au niveau processus (pid=1), une forte dépendance au niveau logique (pas d'indépendance des processus d'init du service), une configuration intermédiaire, la gestion des logs, la gestion matérielle, et même la gestion du bind réseau.
Il implique donc que la configuration d'un service ne se fait pas de la même manière que sur un autre système d'init.

Systemd a été pensé pour un usage desktop avant tout et il est vrai que Redhat a poussé son usage globalement sur linux, ce qui a été critiqué énormément, notamment en usage serveur où la granularité de la philosophie UNIX en général a été complètement remise en question, apportant son lot de problématique autant sur le plan théorique que pratique.

Dans l'open source, la critique est bienvenue et permet au final de faire avancer les choses et certains principes antiques sont toujours d'actualité car nous n'avons pas changé fondamentalement l'informatique malgré son évolution.
Le système d'exploitation fait le lien entre le logiciel et le matériel hors nous sommes toujours sur une architecture matérielle de type Von Neumann datant quand même de 1945.

Tout cela pour dire que la norme peut être remise en question et que certaines technologies peuvent être adaptées dans des contextes et pas du tout dans d'autres. Linux se voulant être un système généraliste multi-plateformes et multi-usages (grid computing, mainframe, serveurs, desktop, téléphone, IOT...), toute modification de ses paradigmes apportent son lot de critiques car il est, en pratique, difficile qu'une nouvelle technologie puisse couvrir tous les usages sans effet de bord par rapport à l'existant.
Systemd, tout comme les scheduleurs CPU du kernel pour cité un autre exemple, ou comme tout autre changement ayant des implications fortes selon le contexte d'usage se doit d'être critiqué pour s'assurer des conséquences et aboutissants à l'usage, voir de se passer complètement de la technologie en question dans certains cas ou les conséquences serait-elle que l'usage ne peut plus être garanti.

Un forum a ses règles mais doit rester un espace ouvert. Je ne vois pas de bashing mais de la critique (au sens premier du terme: que les arguments soit positifs ou négatifs) d'une technologie modifiant la manière de configurer un service donné.

Fin de digression en ce qui me concerne.

On en parle pas. Cela doit être ultra-sensible. Mais il existe aussi la cyberdéfense par l'attaque. Ce serait sûrement plus efficace que de se cacher derrière un port.