La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: vivien le 21 décembre 2023 à 20:50:27
-
Changer le port d'écoute de SSH, sur Ubuntu 24.04 LTS
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).
Depuis Ubuntu 22.10, cela ne se fait plus de la même façon, c'est systemd qui contrôle le port d'écoute de SSH : modifier le port sur /etc/ssh/sshd_config ne sert plus à rien.
Voici donc comment changer le port de SSH : (édit : Tutoriel modifié suite aux retours ci-dessous)
- Ubuntu 23.10 / Ubuntu 24.04 LTS Le port d'écoute de SSH se configure dans systemd :
sudo systemctl edit ssh.socket
Ajouter les 3 lignes suivantes :
[Socket]
ListenStream=
ListenStream=2222 (En remplaçant 2222 par le port de votre choix, prendre de préférence un port au-dessus de 10 000)
(https://lafibre.info/testdebit/ubuntu/202401_tuto_ubuntu_changer_port_ssh.webp)
Application des paramètres : sudo systemctl daemon-reload puis sudo systemctl restart ssh, mais vous pouvez simplement redémarrer le PC.
- Ubuntu 18.04 LTS / 20.04 LTS / 22.04 LTS Le port d'écoute de SSH se configure dans sshd_config
sudo nano /etc/ssh/sshd_config
Changer la ligne #Port 22 par Port 2222, puis redémarrez le PC.
-
Salut Vivien,
Merci pour l'info. Tu testes déjà la 24 ?
Peut-être qu'utiliser les edit / override serait plus judicieux ?
https://askubuntu.com/a/659268
Peut-être quelque chose du genre.
systemctl edit ssh.socket
Pierre
-
Non, je suis sous Ubuntu 23.10, mais peu de personnes utilisent les versions intermédiaires d'Ubuntu pour les serveurs.
Par contre, la question sera posée régulièrement lors de la sortie d'Ubuntu 24.04 LTS, d'où mon idée d'indiquer directement Ubuntu 24.04 LTS pour que les utilisateurs puissent trouver une réponse.
C'est arrivé avec Ubuntu 22.10. J'ai pensé à un bug. Quand j'ai vu qu'il n'était pas non plus possible de changer le port SSH avec Ubuntu 23.10, je me suis dit que cela n'était plus un bug, mais une modification de la méthode pour changer le port SSH mal documenté.
Je sens que certains vont encore taper sur systemd. À chaque nouvelle version, il prend en charge de nouvelles choses (avec Ubuntu 22.04 LTS c'était le DNS, perte du DNS quand on réalisait la mise à jour d'un serveur Ubuntu 20.04 => 24.04)
-
Oui pas de soucis. Je me suis juste demandé s'il y avait des images déjà assez stable pour tester ;)
-
c'est à se demande à quoi va finir par servir le /etc si çe ne sert que de path pour les fichiers de conf auto générés. ::)
-
Peut-être qu'utiliser les edit / override serait plus judicieux ?
Je suis du même avis. Editer directement le fichier dans /lib c'est risquer l'écrasement lors d'une mise à jour de systemd.
-
Le principe de 'activation socket' de systemd est que le service pour ce port n'est pas lancé tant qu'une connexion n'a pas eu lieu, ce qui en pratique est bien (moins de conso mémoire, moins de process qui tournent). C'est surtout utile quand a de nombreuses petites instances (containers lxd par exemple).
Sur archlinux ils ont désactivé l'utilisation de ssh.socket a cause d'un risque de DoS (voir https://wiki.archlinux.org/title/OpenSSH#Daemon_management )
la méthode pour désactiver cela sur Debian/Ubuntu :
systemctl disable --now ssh.socket
rm -f /etc/systemd/system/ssh.service.d/00-socket.conf
rm -f /etc/systemd/system/ssh.socket.d/addresses.conf
systemctl daemon-reload
systemctl enable --now ssh.service
et ensuite on met le port classiquement dans /etc/ssh/sshd_config (ou le .d)
Apres une bonne pratique c'est plutôt de ne pas utiliser de mots de passe pour ssh, c'est bien plus robuste que de changer le port.
ps: le coupable ici n'est pas systemd mais les distribs qui ont voulu utiliser la feature "socket activation" pour sshd :)
-
Sur archlinux ils ont désactivé l'utilisation de ssh.socket a cause d'un risque de DoS
Le risque de DDOS était que trop de connexions à un serveur sshd, configurées à l'aide de 'activation socket' de systemd, peuvent entraîner la désactivation permanente du socket ("sshd.socket: Trigger limit hit, refusing further activation.").
=> https://bugs.archlinux.org/task/62248
Ce problème a été remonté en avril 2019, 4 ans avant que Canonical comment à le mettre dans Ubuntu (l'activation socket pour sshd est arrivé avec Ubuntu 22.10)
Pour moi, cela a été corrigé.
-
Oui mais malgré la correction du bug, les devs d'ArchLinux ne sont pas revenu a sshd.socket.
En pratique c'est au sysadmin de choisir, sur une machine ou il est sur que ssh sera utilisé il n'y a peu d'intérêt a sshd.socket, autant démarrer sshd au boot.
Sur une machine ou l'utilisation de ssh reste exceptionnelle (par exemple de temps a autre pour pousser une config/maj avec Ansible), l'activation par le socket a plus de sens.
Le changement vers sshd.socket impacte d'autres choses ,notamment les noms dans les logs, etc. Dans les environnements fortement monitoré avec des outils de centralisation et de supervision , des adaptations sont nécessaires.
L'important c'est d'être bien informé de tout ca.
-
Il me semble que seules les nouvelles installations sont concernées par le passage à "socket activation" pour sshd.
Les mises à jour restent dans leur configuration d'origine.
-
Tout n'est pas sec.
1/ sudo nano /lib/systemd/system/ssh.socket
J'ai changé ListenStream=22 par le port 4422 : ListenStream=4422
(https://lafibre.info/testdebit/ubuntu/202312_ubuntu_changer_port_ssh.webp)
Application des paramètres : sudo systemctl daemon-reload puis sudo systemctl restart ssh, mais vous pouvez simplement redémarrer le PC.
2/ Mise à jour de sécurité OpenSSH (CVE-2021-41617 (https://ubuntu.com/security/notices/USN-6565-1)) : Le fichier /lib/systemd/system/ssh.socket est mis à jour (pour quelle raison ? je ne vois pas de modification) et écrase le port configuré !
Ci-dessous, entre les deux "cat", j'ai fait les mises à jour de sécurité. On voit le changement de port (et de rien d'autre).
(https://lafibre.info/testdebit/ubuntu/202401_ubuntu_changer_port_ssh.webp)
-
Changer le port d'écoute de SSH, sur Ubuntu 24.04 LTS
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).[...]
bien que j'ai toujours entendu la recommandation de fortement préférer l'auth par certif' au lieu du mdp, j'imagine que changer le port doit être une protection supp'.
mais alors que la suite dirigerait normalement vers le fail2ban, un internaute parmi les grenouilles a publié ceci, déjà bientot adopté dans les dépots d'alpine, pour alléger la chose (en go/C au lieu de python)
ca risque de sortir sur les internets de france, navarre et sans doute niveau worldwide)
https://linuxfr.org/news/reaction-remplacant-de-fail2ban
-
Tout n'est pas sec.
Mise à jour de sécurité OpenSSH (CVE-2021-41617 (https://ubuntu.com/security/notices/USN-6565-1)) : Le fichier /lib/systemd/system/ssh.socket est mis à jour (pour quelle raison ? je ne vois pas de modification) et écrase le port configuré !
Bah c'est normal, on te l'a dit plus haut... Les fichier dans /lib/systemd ne sont pas considérés comme des fichiers modifiables par l'utilisateur, et sont donc écrasés à chaque mise à jour.
La bonne solution, c'est d'utiliser "systemctl edit ssh.socket" qui va créer un "override" dans /etc/systemd/system. Au chargement, systemd lit la configuration dans /lib/systemd et la surcharge par la configuration dans /etc/systemd.
-
Quand j'utilise sudo systemctl edit ssh.socket, il écoute bien sûr le port demandé, mais il écoute aussi sur le port 22 ! (on a ajouté un port supplémentaire d'écoute et pas remplacé le port 22)
(https://lafibre.info/testdebit/ubuntu/202401_ubuntu_changer_port_ssh_systemctl_edit_ssh.socket.webp)
La bonne méthode ne serait pas de rajouter --full : sudo systemctl edit --full ssh.socket et modifier le port ?
(https://lafibre.info/testdebit/ubuntu/202401_ubuntu_changer_port_ssh_systemctl_edit_--full_ssh.socket.webp)
-
J'apprécie tous les jours un peu plus, le formidable travail de Lennart Poettering...
-
C'est peut-être comme ExecStart, il faut peut-être en définir un "vide" pour "nettoyer" et redéfinir après ?
Genre :
[Socket]
ListenStream=
ListenStream=2222
-
J'apprécie tous les jours un peu plus, le formidable travail de Lennart Poettering...
C'est ironique ?
-
C'est peut-être comme ExecStart, il faut peut-être en définir un "vide" pour "nettoyer" et redéfinir après ?
C'est bien le comportement décrit par la doc (https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html):
ListenStream=, ListenDatagram=, ListenSequentialPacket=
[...]
These options may be specified more than once, in which case incoming traffic on any of the sockets will trigger service activation, and all listed sockets will be passed to the service, regardless of whether there is incoming traffic on them or not. If the empty string is assigned to any of these options, the list of addresses to listen on is reset, all prior uses of any of these options will have no effect.
Donc /etc/systemd override /lib/systemd, mais pas trop. C'est limpide !
-
et ensuite on met le port classiquement dans /etc/ssh/sshd_config (ou le .d)
Si j'en crois le résultat des commandes ci-dessous, c'est aussi comme ça que ça fonctionne sur Fedora :
$ systemctl status sshd |head -7
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Sun 2023-12-31 12:57:55 CET; 1 week 0 days ago
Docs: man:sshd(8)
man:sshd_config(5)
$ man sshd_config|grep "Port "
Port Specifies the port number that sshd(8) listens on. The default is 22. Multiple options of this type are permitted. See also ListenAddress.
-
C'est ironique ?
Tout à fait. :)
-
C'est peut-être comme ExecStart, il faut peut-être en définir un "vide" pour "nettoyer" et redéfinir après ?
J'avais oublié ce "détail" effectivement.
-
Salut à tous.
Je ne comprends pas ce besoin de changer la numérotation des ports pour se protéger d'une intrusion.
Je retrouve le même problème avec les ports 80 et 443 qui sont changés systématiquement dans WampServer.
Une des raisons est l'usage de "Skype" ainsi que de "IIS" installées dans votre Windows, qui utilisent les mêmes ports.
Le mieux est encore de les désinstaller pour ne pas avoir ce genre de problème.
J'ai un site web que j'accède à distance par le port 22.
Pour me protéger, j'utilise une clef ssh public qui se trouve renseignée dans le fichier "Authorized_keys", du répertoire ".ssh" à la racine de mon compte utilisateur.
Dans mon ordinateur, celui qui va me servir à me connecter à distance, je possède la clef ssh privée.
J'accède par Putty, qui a été configuré en conséquence, et j'entre sans que l'on me demande mon compte et mon mot de passe.
Quelqu'un qui n'a pas cette clef ssh devra s'identifier en précisant le compte et son mot de passe qui, bien sûr, a été renseigné d'une manière compliquée.
Il y a aussi une autre façon de protéger l'accès par le port 22, en autorisant uniquement certaines adresses IP dans iptables.
Cela implique d'avoir une adresse ip fixe, sinon cette astuce ne fonctionne pas.
-
Je ne comprends pas ce besoin de changer la numérotation des ports pour se protéger d'une intrusion.
C'est une question de plage de scan.
Quand tu recherches une vulnérabilité, tu es beaucoup plus efficace si tu connais d'avance le port et le protocole.
Donc, je pense que sur des recherches massives, c'est efficace surtout au-dessus de 1024.
Après sur une recherche ciblée, c'est à mon avis sans efficacité. Le port knocking peut être une solution.
Le problème, c'est surtout d'imposer ce changement massif. Comme c'est massif, tu rajoutes SSH 2222 aux scanner et retour à la case départ.
Enfin, ce port est dans la plage utilisateur, il y a peut-être moyen d'empêcher le démarrage d'un processus système avec un processus utilisateur...
Bref ça sent la fausse bonne idée à mon avis.
Le pire, c'est si tu te retrouves derrière un firewall filtre les sorties, quand les ports sont non standard ... C'est mort.
A+
-
TCP 2222, c'est un exemple, ce n'est pas forcément le plus pertinent.
Je conseille de mettre SSH au-delà de 10 000 premiers ports, car les 10 000 premiers ports sont plus scannés que les autres.
Cela oblige l'attaquant à scanner 65000 ports et plus il scan de port, plus il peut se fait repérer et bloquer.
Changer le port est une mesure gratuite qui permet d'augmenter le niveau de sécurité pour pas cher et qui est compatible avec d'autres mesures de protection.
-
Changer le port est une mesure gratuite qui permet d'augmenter le niveau de sécurité pour pas cher et qui est compatible avec d'autres mesures de protection.
Surtout sur un serveur comme lafibre.info qui est très "visible" et subit des attaques régulièrement.
-
C'est une question de plage de scan.
Même pas, car l'important est de bien configurer son firewall afin que tous les ports non ouverts soient invisibles.
J'utilise le site de "Gibson Research Corporation (https://www.grc.com/intro.htm)" pour vérifier l'état des ports.
Pour les ports ouverts, j'ai créé des règles entrantes et sortantes pour interdire les accès que je n'autorise pas.
Dans mes Raspberry Pi, je peux interdire l'accès au compte ROOT. Cela se fait dans le fichier "sshd_config".
Mais je fais mieux, j'interdis tous les accès qui ne se font pas par certificat SSH. Donc aucun accès par login et password.
Pour les ports 80 & 443, j'ai configuré Apache afin d'interdire certaines connexions.
Par exemple interdire une liste d'adresses IP. Ou encore uniquement des accès en protocole HTTP2.
Bref ça sent la fausse bonne idée à mon avis.
Je suis du même avis que toi.
Changer le port est une mesure gratuite qui permet d'augmenter le niveau de sécurité pour pas cher et qui est compatible avec d'autres mesures de protection.
Tu peux modifier et mettre n'importe quel port à la place du 22 dans ton ordinateur, l'important est le port qui te sert sur internet, pour entrer dans ta box et ensuite être rediriger (NAT) vers ton ordinateur. Au final, avec un scan, on peut retrouver le port qui sert comme point d'entrée de ta Box. Donc, ce que tu fais ne sert strictement à rien. Ce n'est pas ça qui va augmenter la sécurité de ton ordinateur. Pour assurer les accès, il faut utiliser des certificats SSH.
@+
-
Bonjour artemus24,
Je crois que nous connaissons bien ces subtilités ;) .
Ce qu'il te manque peut-être comme connaissance, ce sont les techniques des "pirates".
Imaginons que ton firewall et ton NAT sont bien configurés pour autoriser que le port 22. S'il y a une faille dans ton serveur SSH, des mots de passe faible, des collisions une clé SSH ( ce que tu appelles probablement un certificat ), etc ....
Les pirates pourront rapidement le trouver en scannant toutes les adresses IPs d'internet sur le port 22.
Si tu changes le port par défaut par un port "aléatoire", tu conserves ta fonctionnalité. Ça devient beaucoup plus compliqué pour les pirates.
Ils doivent scanner environ 60000 ports de plus.
- Donc ça prend +/- 60000 fois plus de temps.
- Ils ont beaucoup plus de chances de se faire détecter et de se faire blacklister.
Bref l'idée de base est intéressante et ne coute pas cher si le port est aléatoire et assez haut dans la plage.
Maintenant en fixant un autre port et surtout le 2222 ( qui est un grand classique ), à mon avis, on pisse dans un violon.
Si tu veux continuer dans la sécurisation de ton RPI, tu peux regarder le port knocking, des outils comme fail2ban, crowdsec, les VPN, etc ...
A+
-
Je ne comprends pas encore le choix du port 2222, mais le passage par systemd à deux vocations :
- démarrer plus vite
- consommer moins de ressources
https://dev.to/sneh27/maximizing-efficiency-socket-based-ssh-activation-in-ubuntu-2210-and-above-344b
A+
-
Le port 2222 est un exemple, je précise bien qu'il faut le changer pour un port supérieur à 10 000.
Que root ne puisse pas se connecter en SSH, c'est la base de la base, bien plus important que changer le port.
Dans la plupart des scans SSH, le user est root.
Pour revenir à la méthode pour changer de port, un grand merci macmonac, c'est exactement ce qu'il fallati faire : (j'ai testé)
C'est peut-être comme ExecStart, il faut peut-être en définir un "vide" pour "nettoyer" et redéfinir après ?
Genre :
[Socket]
ListenStream=
ListenStream=2222
Je vais diffuser ce tutoriel sur les sites comme https://www.ubuntu-fr.org/
Ubuntu 23.10 / Ubuntu 24.04 LTS Le port d'écoute de SSH se configure dans systemd :
sudo systemctl edit ssh.socket
Ajouter les 3 lignes suivantes :
[Socket]
ListenStream=
ListenStream=2222 (En remplaçant 2222 par le port de votre choix, prendre de préférence un port au-dessus de 10 000)
(https://lafibre.info/testdebit/ubuntu/202401_tuto_ubuntu_changer_port_ssh.webp)
Application des paramètres : sudo systemctl daemon-reload puis sudo systemctl restart ssh, mais vous pouvez simplement redémarrer le PC.
-
Merci Vivien,
J'avais oublié le début du post. Désolé ;).
Donc 2222 -> C'est pour l'exemple
Le passage à systemd -> C'est pour les perfs
Un autre exemple avec ces mêmes explications trouvé en cherchant le pourquoi du comment : https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189/9
A+
-
Je vais diffuser ce tutoriel sur les sites comme https://www.ubuntu-fr.org/
Je viens de vérifier sur Fedora (39, installation "fraîche"), c'est bien /etc/ssh/sshd_config qu'il convient de modifier (directive Port).
Plus évidemment une petite modification SELinux par # semanage port -a -t ssh_port_t -p tcp XXXXX et la mise à jour des règles de firewall.
-
Merci Macmonac pour tes réflexions très pertinente. :)
Ce qu'il te manque peut-être comme connaissance, ce sont les techniques des "pirates".
Je crains que oui. :)
J'ai fréquemment des tentatives d'intrusions avec mon site web de test que j'héberge dans mon Windows.
Grâce à Apache du serveur WampServer, ainsi qu'au pare-feu de Windows, j'arrive à bien me protéger.
Et quand je détecte des petits malins qui sont trop insistant, j'interdis leur adresse IP.
Maintenant en fixant un autre port et surtout le 2222 ( qui est un grand classique ), à mon avis, on pisse dans un violon.
Nous sommes bien d'accord.
Tôt ou tard, les pirates trouveront ce nouveau port. Donc, ce n'est pas la bonne méthode.
Celle que je privilègie le plus, en dehors des clef SSH, est le pare-feu.
Si tu veux continuer dans la sécurisation de ton RPI, tu peux regarder le port knocking, des outils comme fail2ban, crowdsec, les VPN, etc ...
Je n'utilise pas les VPN commerciaux comme ceux de NORDVPN qui coute de l'argent et ne servent strictement à rien pour se protéger.
J'ai jadis utilisé OpenVPN en le configurant en tant que serveur dans ma Raspberry Pi et en tant que client dans mon portable. Ca fonctionnait impécable.
Pourquoi j'ai abandonné "OpenVPN" ? J'accède depuis l'internet à partir d'adresses IP fixes.
J'ai configuré les "iptables" et "ip6tables" de ma Raspberry PI pour ne laisser passer que le flux venant de ces adresses IP.
Je connais "fail2ban" mais je ne l'utilise pas.
"crowdsec", je ne connais pas, mais je crois qu'il fait presque la même chose que "fail2ban".
Je vais jeter un œil sur le port knocking que je ne connais pas du tout.
En dehors de ma clef SSH, et des adresses IP fixes (pare-feu), je n'utilise aucune autres solutions sécuritaires.
Si les adresses IP sont dynamiques, je n'ai pas de solutions, sauf ajouter la saisie d'un identifiant et d'un mot de passe supplémentaire.
Je précise aussi qu'il faut renommer son compte "pi" utilisateur en autre chose, connue seulement que de vous.
Je ne conseille pas d'installer des applications pare-feu car ils peuvent posséder des portes dérobées.
Ce qui permet à son concepteur ou à la société qui le commercialise de venir visiter votre ordinateur quand il le veut.
Comme toute chose, il faut s'investir dans la sécurité et faire beaucoup de tests pour fiabiliser ce que l'on met en place.
-
Pour la sécurité, une bonne chose est de demander à SSHd de ne pas écouter en IPv4 et d'écouter uniquement en IPv6 sur une IPv6 dédiée à son usage qui contient des bits aléatoires et non l'IPv6 séquentielle suivante de l'IPv6 web.
J'ai peur que avec systemd, les lignes que je rajoute habituellement dans /etc/ssh/sshd_config.d/ ne fonctionnent plus
AddressFamily inet6
ListenAddress [2103:b860:de01:1100:2200:abcd:ef01:1100]
Le changement de port est un plus pour cacher SSHd (il faut trouver l'IPv6 et le port).
-
Sinon SSHd ne devait pas être utilisé par inetd : "sshd is normally not run from inetd because it needs to generate the server key before it can respond to the client, and this may take tens of seconds. Clients would have to wait too long if the key was regenerated every time." (source (https://twitter.com/RenaudGuerin/status/1744678383215092032))
Comment fait systemd pour cette clé serveur ? (c'est toujours d'actualité ? SShd ne met pas 10 secondes à se lancer aujourd'hui.
Cette clé serveur, c'est celle générée lors de l'installation de sshd, non ? (là oui, cela met une dizaine de secondes)
-
C'est ssh 1 qui fonctionnait comme cela (regen clé toutes les heures). Ssh 2 n'a pas ce souci.
-
Surtout sur un serveur comme lafibre.info qui est très "visible" et subit des attaques régulièrement.
la bonne "pratique" c'est qu'un site comme lafibre.info ne devrait pas avoir de port ssh ouvert sur aucune de ses IPs connus. (v4 et v6 donc). point barre.
-
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 suis relativement attristé que cela ne choque personne.
On en est à changer la configuration d'un service en utilisant un autre service, qui se substitue à la configuration d'origine, en l'écrasant en silence ?
Unix, et GNU/Linux n'est qu'une implémentation libre de ce paradigme, c'est un noyau, et des services autour. Les services peuvent si on le désire produire des journaux qui sont des fichiers contenant du texte. Quand quelque chose foire on peut lancer un grep dessus, car, "grep, c'est mieux que tes yeux", faire des traitements dessus si l'on veut, et régler vite le problème.
J'ai été amené à vouloir modifier la configuration d'une instance MariaDB, et j'ai mis quelques trop longues minutes d'incompréhension à réliser que systemd écrasait la configuration de MariaDB.
Sérieusement, mais de quel droit ?
Quelle est l'hallucination collective qui rend normal le remplacement d'un système efficace, qui marche, par un système centralisé obscur qui produit des logs binaires ?
Je sais bien tous ceux qui n'ont jamais utilisé que systemd vont me prendre pour un vieux dinosaure débile trop bête pour utiliser systctl, encore lire des journaux systèmes en texte, aimer régler rapidement les problèmes de configuration qui se posent, mais là on en est à un thread de 4 pages pour changer le port d'écoute de sshd...
Je rappelle à l'aimable et estimé auditoire de ce fil, que je saupoudre d'infiniment d'amour, que OpenRC existe, et qu'il règle simplement tous les problèmes que vous évoquez, à l'ancienne, de façon efficace et simplement simple ?
J'apprécie tous les jours un peu plus, le formidable travail de Lennart Poettering...
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 ?
-
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 (https://lafibre.info/serveur-linux/changer-le-port-de-ssh-ubuntu-24-04/msg1049999/#msg1049999) (mais sans être allé plus loin qu'un test de base).
Ah, au fait, il faut aussi maîtriser SELinux (https://fr.wikipedia.org/wiki/SELinux), tu ne parles pas de cet autre empêcheur de tourner en rond.
-
Primo et sans partir dans un débat anti/pro systemd, le fautif dans le cas présent n'est pas systemd mais les distros qui ont choisi d'utiliser la fonctionnalité socket de systemd (qui permet de démarrer un service qu'a la premiere connexion sur un port, chose qu'OpenRC ne fait pas il me semble ?).
On voit aussi trop de gens qui publie des config systemd de services sans maitriser la chose d'où écrasement de config et autre joyeuseté. Ce n'est pas juste de critiquer la voiture quand le problème c'est le conducteur.
Deuxio, l'évolution c'est des OS complètement managés via des logiciels plus haut niveau de gestion de configs de VMs, centralisation des logs et supervision. C'est certain que celui qui fait encore des trucs en direct 'a la main' sur son OS pourra se plaindre de cet évolution. Encore que si on 'apprend bien' systemd c'est assez simple et logique (le problème est qu'on ne prend plus le temps d'apprendre "bien", on se contente de chercher sur Google une solution publiée sur stackexchange ou autre et qui n'est pas forcément correcte...).
Perso je n'ai pas de souci avec systemd mais plus avec ceux qui s'en servent mal.
-
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), une feature que systemd propose et que certains distros on souhaiter utiliser pour ssh.
sans systemd tu n'a plus cette feature. qu'elle soit nécessaire ou pas c'est ca le débat (un serveur qui veut sshd tout le temps actif n'a pas besoin de scoket systemd pour sa config du port ssh).
"devoir passer par la configuration de systemd pour configurer un service donné" , n'a jamais été obligé c'est un choix des distros.
-
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...
-
Mon propos: stop le bash sur systemd qui n'est pas le responsable des choix de ceux qui l'utilisent. on a 4 pages parce que des gens confondent les causes et les conséquences.
on n'a jamais dit non plus que l'activation à la première connexion était un feature inédite, juste que vu que quasi tous les distribs utilisent maintenant systemd, autant utilisé systemd pour cette feature si on en a *vraiment* besoin.
Que ce soit pertinent pour sshd c'est plus ca la question, systemd ou n'importe quel autre système d'activation.
Il y a des cas *modernes* ou cette feature peut etre utile mais évidemment pas pour un cas d'usage comme présenté ici , qui est un cas d'usage "antique" classique LAMP comme on faisait y'a 20 ans ou plus donc évidemment un peu décalé avec les technos d'aujourd'hui - et ce n'est pas un jugement de valeur mais faut juste avoir ca en tête quand on *juge* ces technos dans ce contexte.
-
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.
-
Je n'ai rien contre la critique de systemd bien au contraire. la le probleme n'est pas systemd lui meme mais le fait de l'utiliser pour ca et ensuite blâmer systemd ou de mal l'utiliser (modif en dossier lib par exemple).
-
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.
-
Ou écouter le port 22 et bloquer toutes les IP qui s'y présentent, vu que c'est des scans (au mieux) ou des attaques.
-
Je n'ai rien contre la critique de systemd bien au contraire. la le probleme n'est pas systemd lui meme mais le fait de l'utiliser pour ca et ensuite blâmer systemd ou de mal l'utiliser (modif en dossier lib par exemple).
Désolé d'ajouter une pièce dans la machine, mais c'est bien systemd qui est en cause dans ce thread, avec son fonctionnement stupide qui oblige à déclarer une variable nulle dans la conf /etc pour écraser ensuite avec la même variable la conf par défaut de /lib (cf réponse de mactomac https://lafibre.info/serveur-linux/changer-le-port-de-ssh-ubuntu-24-04/msg1049875/#msg1049875 (https://lafibre.info/serveur-linux/changer-le-port-de-ssh-ubuntu-24-04/msg1049875/#msg1049875))
Pour le reste, chacun a bien le droit de saisir l'opportunité d'utiliser/tester systemd.socket.
-
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).
J'ai découvert des mentions au moteur de recherche Shodan (https://fr.wikipedia.org/wiki/Shodan_(site_web)) dans un livre et une vidéo. Cela m'a donné le vague sentiment que chaque machine connectée à l'Internet peut potentiellement être recensée.
Cela peut permettre à des personnes malveillantes ayant ces informations et des compétences en la matière de rechercher et d'exploiter des vulnérabilités systématiquement (de façon ciblée).
Tout cela pour mettre en exergue que les pirates informatiques peuvent en savoir beaucoup et ne pas prendre les choses telles quelles (en déformant).
-
Ubuntu 24.04 est sortie et il faut bien changer le port avec sudo systemctl edit ssh.socket
Pour rappel, le changement est porté par plusieurs objectifs, dont le principal est de réduire l'empreinte mémoire des conteneurs Ubuntu.