Bonjour à toutes et tous,
J'ai, comme tout le monde j'imagine, de la brute force via ssh, qui déclenche le très agaçant message en console
"fatal: Read from socket failed: Connection reset by peer [preauth]"
Ici y'a que de la clé (et passwords invalidés) je ne peux pas filtrer sur les IP entrantes, ni changer le port 22, le plus simple me semble donc d'ignorer la chose.
J'ai googlé et ducké sans succès pour voir s'il y avait un moyen de dire au démon sshd de limiter sa prose aux fichiers de logs sans polluer la console.
man sshd ou man sshd_config ne m'ont rien dit de sympa (mais j'ai peut être raté une ligne).
Avez-vous une opinion ? Ça serait bien de faire un ménage de printemps :)
https://unix.stackexchange.com/questions/13019/description-of-kernel-printk-... https://unix.stackexchange.com/questions/13019/description-of-kernel-printk-values
Le 25 avr. 2024 à 14:46, Stéphane Rivière stef@genesix.org a écrit :
Bonjour à toutes et tous,
J'ai, comme tout le monde j'imagine, de la brute force via ssh, qui déclenche le très agaçant message en console
"fatal: Read from socket failed: Connection reset by peer [preauth]"
Ici y'a que de la clé (et passwords invalidés) je ne peux pas filtrer sur les IP entrantes, ni changer le port 22, le plus simple me semble donc d'ignorer la chose.
J'ai googlé et ducké sans succès pour voir s'il y avait un moyen de dire au démon sshd de limiter sa prose aux fichiers de logs sans polluer la console.
man sshd ou man sshd_config ne m'ont rien dit de sympa (mais j'ai peut être raté une ligne).
Avez-vous une opinion ? Ça serait bien de faire un ménage de printemps :)
-- Stéphane Rivière Ile d'Oléron - France
Liste de diffusion du %(real_name)s http://www.frsag.org/
Le Thu, Apr 25, 2024 at 02:46:37PM +0200, Stéphane Rivière a écrit:
Avez-vous une opinion ? Ça serait bien de faire un ménage de printemps :)
Une double solution...
1/ autoriser tout ce que tu connais et qui a une IP fixe 2/ pour les autres, ouvrir le port après un port-knocking.
Plus de problème de logs ou de tentatives dégueux.
Arnaud.
Ce n'est pas forcément lié, mais j'ai fini par sauter le pas de changer le port de sshd sur mes rebonds, c'est de la sécurité par l'obscurité, je n'aime pas, mais ca m'a permis d'avoir un endlessh sur le port 22, et de d'occuper un peu les kiddies qui tentent du bruteforce.
si jamais tu as un prometheus qui traine, tu peux en plus avoir la satisfaction d'un beau dashboard qui te montre qui tu as emm*rdé et pendant combien de temps :-)
https://github.com/shizunge/endlessh-go
J'ai aussi tenté par le passé les règles de firewalling basées sur des données geoip, ça n'élimine pas tout mais ca réduit drastiquement le traffic de certains pays sur-représentés dans les attaques par force brute (faut juste pas baser toute sa sécurité dessus, et être prêt à gérer l'erreur de localisation d'une IP par Maxmind)
Le 25/04/2024 à 17:29, Sebastien Guilbaud a écrit :
c'est de la sécurité par l'obscurité,
C'est la mesure la plus efficace (sauf si c'est la seule).
je n'aime pas, mais ca m'a permis d'avoir un endlessh sur le port 22, et de d'occuper un peu les kiddies qui tentent du bruteforce.
Changer le port ssh a l'inconvénient de sortir du standard ; si l'administration devait être reprise par quelqu'un d'autre, ce serait une source de galère supplémentaire.
De plus, les tentatives de connexions ssh permettent de faire une moisson d'adresse IP à bloquer. Sans être un expert en attaque, je me dis que même les pirates pro (pas les kiddies donc) ne doivent pas se priver de commencer à tester le port 22 et là, paf, il sont bloqués avant de mettre en œuvre des techniques d'attaques plus avancées ou plus larges que celles des kiddies.
Tu peux toujours mettre sur le port 22 un honeypot avec un shell sandboxé, qui a comme prompt:
WOPR>
Le 25 avr. 2024 à 18:27, Laurent Barme 2551@barme.fr a écrit :
Le 25/04/2024 à 17:29, Sebastien Guilbaud a écrit :
c'est de la sécurité par l'obscurité,
C'est la mesure la plus efficace (sauf si c'est la seule).
je n'aime pas, mais ca m'a permis d'avoir un endlessh sur le port 22, et de d'occuper un peu les kiddies qui tentent du bruteforce.
Changer le port ssh a l'inconvénient de sortir du standard ; si l'administration devait être reprise par quelqu'un d'autre, ce serait une source de galère supplémentaire.
De plus, les tentatives de connexions ssh permettent de faire une moisson d'adresse IP à bloquer. Sans être un expert en attaque, je me dis que même les pirates pro (pas les kiddies donc) ne doivent pas se priver de commencer à tester le port 22 et là, paf, il sont bloqués avant de mettre en œuvre des techniques d'attaques plus avancées ou plus larges que celles des kiddies.
Liste de diffusion du %(real_name)s http://www.frsag.org/
Le 25/04/2024 à 17:29, Sebastien Guilbaud a écrit :
c'est de la sécurité par l'obscurité,
C'est la mesure la plus efficace (sauf si c'est la seule).
bof, se dire que les vilains ne trouveront pas le service ssh vu que tu l'as mis sur un autre port, ca peut donner une fausse sensation de sécurité, c'est ce que j'appelle la sécurité par l'obscurité. C'est dommage de tomber sur cette technique en première étape de tutos à neuneus qui ne prennent même pas la peine de bloquer l'authentification par mot de passe ou jouer un peu avec MaxStartups pour réduire le débit des bruteforce.
La mesure réellement la plus efficace, c'est que le service ne soit pas ouvert à tous vents. (filtrage sur IP source, VPN ou port knocking comme dit plus haut)
Changer le port ssh a l'inconvénient de sortir du standard ; si l'administration devait être reprise par quelqu'un d'autre, ce serait une source de galère supplémentaire.
Argument recevable mais alambiqué. Si tu refiles l'admin à quelqu'un d'autre, tu remets tous les sshd exposés sur le port 22 et basta
et quand tu distribues la conf ssh versionnée à tous les collègues pour accéder à toutes les machines derrière le rebond, c'est un non-problème. (Merci openssh 7.3p1+ et ~/.ssh/config.d/)
De plus, les tentatives de connexions ssh permettent de faire une moisson d'adresse IP à bloquer. Sans être un expert en attaque, je me dis que même les pirates pro (pas les kiddies donc) ne doivent pas se priver de commencer à tester le port 22 et là, paf, il sont bloqués avant de mettre en œuvre des techniques d'attaques plus avancées ou plus larges que celles des kiddies.
toi, t'as pas regardé ce que fait endlessh :) ça ne bloque rien, tu collectes aussi les adresses des attaquants si ça t'intéresse, mais tu leur fais surtout perdre du temps avec une réponse protocolairement correcte, juste très lente. (en consommant très peu de ta bande passante, même avec un grand nombre d'attaquants simultanés)
Le 25/04/2024 à 23:07, Sebastien Guilbaud a écrit :
Le 25/04/2024 à 17:29, Sebastien Guilbaud a écrit : > c'est de la sécurité par l'obscurité, C'est la mesure la plus efficace (sauf si c'est la seule).bof, se dire que les vilains ne trouveront pas le service ssh vu que tu l'as mis sur un autre port, ca peut donner une fausse sensation de sécurité, c'est ce que j'appelle la sécurité par l'obscurité.
Ma remarque sur l'importance de la discrétion dans la sécurité est générale et ne concerne pas que le changement de port d'un service standard. La "sécurité par l'obscurité" est une meilleure approche que sa réputation ne le laisse entendre.
C'est dommage de tomber sur cette technique en première étape de tutos à neuneus qui ne prennent même pas la peine de bloquer l'authentification par mot de passe ou jouer un peu avec MaxStartups pour réduire le débit des bruteforce.
La mesure réellement la plus efficace, c'est que le service ne soit pas ouvert à tous vents. (filtrage sur IP source, VPN ou port knocking comme dit plus haut)
Effectivement, croire que le seul changement de port protègerait est vraiment naïf. Quant à la protection par simple mot de passe sur un accès ssh, c'est une technique obsolète.
Changer le port ssh a l'inconvénient de sortir du standard ; si l'administration devait être reprise par quelqu'un d'autre, ce serait une source de galère supplémentaire.Argument recevable mais alambiqué. Si tu refiles l'admin à quelqu'un d'autre, tu remets tous les sshd exposés sur le port 22 et basta
Je pensais à une reprise sans transfert ni préalable…
et quand tu distribues la conf ssh versionnée à tous les collègues pour accéder à toutes les machines derrière le rebond, c'est un non-problème. (Merci openssh 7.3p1+ et ~/.ssh/config.d/)
De plus, les tentatives de connexions ssh permettent de faire une moisson d'adresse IP à bloquer. Sans être un expert en attaque, je me dis que même les pirates pro (pas les kiddies donc) ne doivent pas se priver de commencer à tester le port 22 et là, paf, il sont bloqués avant de mettre en œuvre des techniques d'attaques plus avancées ou plus larges que celles des kiddies.toi, t'as pas regardé ce que fait endlessh :) ça ne bloque rien, tu collectes aussi les adresses des attaquants si ça t'intéresse, mais tu leur fais surtout perdre du temps avec une réponse protocolairement correcte, juste très lente. (en consommant très peu de ta bande passante, même avec un grand nombre d'attaquants simultanés)
J'ai suivi le lien que tu nous a indiqué vers endlessh-go. C'est fascinant de pouvoir ainsi visionner, sur une superbe présentation graphique, les pirates "du monde entier" en train de butiner inutilement ton port 22 ! Cela a l'air encore mieux que la télé pour se distraire :-)
Par contre, au niveau amélioration de la sécurité : bof.
Hello,
On Fri, Apr 26, 2024, 09:44 Laurent Barme 2551@barme.fr wrote:
La "sécurité par l'obscurité" est une meilleure approche que sa réputation ne le laisse entendre.
On est d'accord ! La sécurité est un empilement de petits gains, et changer les ports en est un. Plutôt qu'obscurité, c'est un avantage en discrétion.. par exemple en disparaissant de Shodan.
toi, t'as pas regardé ce que fait endlessh :) ça ne bloque rien, tu collectes aussi les adresses des attaquants si ça t'intéresse, mais tu leur fais surtout perdre du temps avec une réponse protocolairement correcte, juste très lente. (en consommant très peu de ta bande passante, même avec un grand nombre d'attaquants simultanés)
J'ai suivi le lien que tu nous a indiqué vers endlessh-go. C'est fascinant de pouvoir ainsi visionner, sur une superbe présentation graphique, les pirates "du monde entier" en train de butiner inutilement ton port 22 ! Cela a l'air encore mieux que la télé pour se distraire :-)
Par contre, au niveau amélioration de la sécurité : bof.
C'est intellectuellement hyper satisfaisant de se dire qu'on va enquiquiner les attaquants par une forme de vengeance, mais en réalité vous ne voulez pas que votre serveur soit celui qui ressort dans les logs comme celui qui a planté leur scanner... Ça attire juste l'attention. D'un point de vue sécurité je dirais même que c'est contreproductif. Pour vivre heureux vivons cachés !
Hello,
Plutôt qu'obscurité, c'est un avantage en discrétion.. par exemple en disparaissant de Shodan
Alors pas tout à fait. Changer le port te permettra juste de ne plus remonter dans les résultats Shodan des services écoutant sur le port 22. Tu apparaitra tout de même dans les résultats des recherches qui ciblent SSH (voir plus précisément sur la version utilisée, etc).
Ex: https://www.shodan.io/search?query=SSH-2.0-OpenSSH_9.7, suffit de trier par "Top port" dans la colonne de gauche.
Si tu veux disparaitre de Shodan (ou tout autre scanner IPv4), je ne connais que ces méthodes :
- passer par un VPN - faire du port knocking - désactiver IPv4 au profit d’IPv6
Cela dit si quelqu’un a d’autres astuces ça m’intéresse.
Cordialement,
Louis
Le Mon, Apr 29, 2024 at 09:52:23AM +0000, Louis G. via FRsAG a écrit:
- passer par un VPN
- faire du port knocking
- désactiver IPv4 au profit d’IPv6
Cela dit si quelqu’un a d’autres astuces ça m’intéresse.
Filtrer les IP autorisées à se connecter, tout simplement ? :)
iptables -A INPUT -s 1.2.3.4/32 -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP
(évidemment, un -P INPUT DROP, et un s/iptables/nft/ est mieux en 2024, mais pour la lisibilité , c'est plus clair)
Arnaud.
On Mon, Apr 29, 2024, 11:52 Louis G. louis.frsag@gatin.cloud wrote:
Alors pas tout à fait. Changer le port te permettra juste de ne plus remonter dans les résultats Shodan des services écoutant sur le port 22. Tu apparaitra tout de même dans les résultats des recherches qui ciblent SSH (voir plus précisément sur la version utilisée, etc).
Ex: https://www.shodan.io/search?query=SSH-2.0-OpenSSH_9.7, suffit de trier par "Top port" dans la colonne de gauche.
Si tu veux disparaitre de Shodan (ou tout autre scanner IPv4), je ne connais que ces méthodes :
- passer par un VPN
- faire du port knocking
- désactiver IPv4 au profit d’IPv6
Si, Shodan ne scanne pas tous les ports TCP, il suffit d'en choisir un élevé et d'éviter cette liste : https://gist.github.com/s0md3v/3e953e8e15afebc1879a2245e74fc90f Mais évidemment ça peut changer d'un jour à l'autre
Le jeudi 25 avril 2024 (17:29), Sebastien Guilbaud écrivait :
Ce n'est pas forcément lié, mais j'ai fini par sauter le pas de changer le port de sshd sur mes rebonds, c'est de la sécurité par l'obscurité,
N'autoriser ssh qu'en IPv6 n'est-il pas aussi une solution pour limiter les scans ?
cordialement
Le 25/04/2024 à 14:46, Stéphane Rivière a écrit :
Bonjour à toutes et tous,
J'ai, comme tout le monde j'imagine, de la brute force via ssh, qui déclenche le très agaçant message en console
"fatal: Read from socket failed: Connection reset by peer [preauth]"
D'après mes notes, ce type de message apparaissait pour une debian 9. Je n'en ai pas avec la 10 :-)
Ici y'a que de la clé (et passwords invalidés) je ne peux pas filtrer sur les IP entrantes, ni changer le port 22, le plus simple me semble donc d'ignorer la chose.
J'ai googlé et ducké sans succès pour voir s'il y avait un moyen de dire au démon sshd de limiter sa prose aux fichiers de logs sans polluer la console.
man sshd ou man sshd_config ne m'ont rien dit de sympa (mais j'ai peut être raté une ligne).
Avez-vous une opinion ? Ça serait bien de faire un ménage de printemps :)
Hello again,
Selon la suggestion (qui me convient bien) de David, je regarde ce que propose Debian par défaut sur une instance de test...
sysctl kernel.printk kernel.printk = 7 4 1 7
Donc je traduis, grâce au lien de David :
console_loglevel = 7 messages with a higher priority than this will be printed to the console default_message_loglevel = 4 messages without an explicit priority will be printed with this priority minimum_console_loglevel = 1 minimum (highest) value to which console_loglevel can be set default_console_loglevel = 7 a priori pas utilisé
Tenté un sysctl -w kernel.printk='4 4 1 7'et si ça devient sage, on scotchera ça dans le sysctl.conf
Et oui Laurent... Bien vu... C'est sur une instance paléolithique (8.11) J'en ai pas énormément des comme ça...
Mais je l'ai aussi sur d'autres plus récentes (11.9)... Donc c'est pas clair et j'ai posé la même commande sur une 11.9 pour voir aussi...
Merci pour votre aide !
Mais non t’es à la bourre de 2/3 mails.
Installe rsyslog, c’est de toute façon plus puissant que syslogd et tu auras plus de messages sur la console, si j’ai bien compris. En tout cas, je n’en ai pas sur mes Debian (10/11/12), sauf si j’ajoute dans rsyslogd.conf: auth.* /dev/console
David
Le 25 avr. 2024 à 18:48, Stéphane Rivière stef@genesix.org a écrit :
Hello again,
Selon la suggestion (qui me convient bien) de David, je regarde ce que propose Debian par défaut sur une instance de test...
sysctl kernel.printk kernel.printk = 7 4 1 7
Donc je traduis, grâce au lien de David :
console_loglevel = 7 messages with a higher priority than this will be printed to the console default_message_loglevel = 4 messages without an explicit priority will be printed with this priority minimum_console_loglevel = 1 minimum (highest) value to which console_loglevel can be set default_console_loglevel = 7 a priori pas utilisé
Tenté un sysctl -w kernel.printk='4 4 1 7' et si ça devient sage, on scotchera ça dans le sysctl.conf
Et oui Laurent... Bien vu... C'est sur une instance paléolithique (8.11) J'en ai pas énormément des comme ça...
Mais je l'ai aussi sur d'autres plus récentes (11.9)... Donc c'est pas clair et j'ai posé la même commande sur une 11.9 pour voir aussi...
Merci pour votre aide !
-- Stéphane Rivière Ile d'Oléron - France _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Un petit retex de la manip, qui ne semble pas concluante...
1265 25/04/2024 18:37:33 sysctl -w kernel.printk=4 4 1 7 1266 25/04/2024 18:37:45 sysctl -w 'kernel.printk=4 4 1 7' 1268 26/04/2024 13:34:26 sysctl -w 'kernel.printk=4 4 1 4' 1274 26/04/2024 14:55:13 sysctl -w 'kernel.printk=3 3 1 3' 1275 28/04/2024 09:13:29 sysctl -w 'kernel.printk=2 2 1 2' 1276 28/04/2024 17:21:07 sysctl -w 'kernel.printk=1 1 1 1'
J'ai toujours le message...
Remis les réglages d'origine : kernel.printk = 7 4 1 7
Bonjour à toutes et tous,
J'ai, comme tout le monde j'imagine, de la brute force via ssh, qui déclenche le très agaçant message en console
"fatal: Read from socket failed: Connection reset by peer [preauth]"
Ici y'a que de la clé (et passwords invalidés) je ne peux pas filtrer sur les IP entrantes, ni changer le port 22, le plus simple me semble donc d'ignorer la chose.
J'ai googlé et ducké sans succès pour voir s'il y avait un moyen de dire au démon sshd de limiter sa prose aux fichiers de logs sans polluer la console.
man sshd ou man sshd_config ne m'ont rien dit de sympa (mais j'ai peut être raté une ligne).
Avez-vous une opinion ? Ça serait bien de faire un ménage de printemps :)
Mais pourquoi tu fais pas ce que je te dis ? :)
David
Le 28 avr. 2024 à 19:24, Stéphane Rivière stef@genesix.org a écrit :
Un petit retex de la manip, qui ne semble pas concluante...
1265 25/04/2024 18:37:33 sysctl -w kernel.printk=4 4 1 7 1266 25/04/2024 18:37:45 sysctl -w 'kernel.printk=4 4 1 7' 1268 26/04/2024 13:34:26 sysctl -w 'kernel.printk=4 4 1 4' 1274 26/04/2024 14:55:13 sysctl -w 'kernel.printk=3 3 1 3' 1275 28/04/2024 09:13:29 sysctl -w 'kernel.printk=2 2 1 2' 1276 28/04/2024 17:21:07 sysctl -w 'kernel.printk=1 1 1 1'
J'ai toujours le message...
Remis les réglages d'origine : kernel.printk = 7 4 1 7
Bonjour à toutes et tous,
J'ai, comme tout le monde j'imagine, de la brute force via ssh, qui déclenche le très agaçant message en console
"fatal: Read from socket failed: Connection reset by peer [preauth]"
Ici y'a que de la clé (et passwords invalidés) je ne peux pas filtrer sur les IP entrantes, ni changer le port 22, le plus simple me semble donc d'ignorer la chose.
J'ai googlé et ducké sans succès pour voir s'il y avait un moyen de dire au démon sshd de limiter sa prose aux fichiers de logs sans polluer la console.
man sshd ou man sshd_config ne m'ont rien dit de sympa (mais j'ai peut être raté une ligne).
Avez-vous une opinion ? Ça serait bien de faire un ménage de printemps :)
-- Stéphane Rivière Ile d'Oléron - France
Liste de diffusion du %(real_name)s http://www.frsag.org/
Hello,
On Sun, 28 Apr 2024 19:32:08 +0200 David Ponzone david.ponzone@gmail.com wrote:
Mais pourquoi tu fais pas ce que je te dis ? :)
Le dimanche, ils se reponsent dans les iles :D
Paul
Ouais, et je connais les petits blancs d’Oléron. Bien frais, ça se boit plutôt tranquille et sans modération :)
David
Le 29 avr. 2024 à 10:31, Paul Rolland (ポール・ロラン) rol+frsag@witbe.net a écrit :
Hello,
On Sun, 28 Apr 2024 19:32:08 +0200 David Ponzone david.ponzone@gmail.com wrote:
Mais pourquoi tu fais pas ce que je te dis ? :)
Le dimanche, ils se reponsent dans les iles :D
Paul _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour
As tu essayé le : kernel.printk = 3 4 1 7 ? (C'est ce qui est choisi, depuis longtemps, dans la distribution LiveRaizo)
David
Dr David ANSART Formateur en Informatique : Réseau Système Cybersécurité Développement C/C++ https://github.com/Raizo62
david.ansart@seineetmarne.cci.fr +33 1 60 37 41 11 CFA UTEC INThttps://www.utec77.fr/ (https://www.utec77.frhttps://www.utec77.fr/) 6 Boulevard Olof Palme CS 60150 Émerainville 77436 Marne-la-Vallée CEDEX 2
[https://ci3.googleusercontent.com/proxy/femEefITJ0c36VknQvisYFKWAiJicpdYWDkX...]https://www.utec77.fr/
[https://ci3.googleusercontent.com/proxy/PrAv608xsWQ17Jtudf-ZkhHZmZ8lh6TXBNnF...]https://www.linkedin.com/company/utec77-cfa-utec [https://ci3.googleusercontent.com/proxy/AIzrqWTFNKF5v5i9fDWhKKJKcXWDJ9Z5hXyo...] https://fr-fr.facebook.com/utec77.formations/ [https://ci6.googleusercontent.com/proxy/8Jn-_XkFHlT_Fo67dJ-_mnkYfmfpCvb5RZXx...] https://twitter.com/utec_77 [https://ci6.googleusercontent.com/proxy/UzISzyJKz18dGYAuUjE0fYjVrb4OXaZRqcDM...] https://www.instagram.com/utec77/?hl=fr
________________________________ De : David Ponzone david.ponzone@gmail.com Envoyé : dimanche 28 avril 2024 19:32 À : Stéphane Rivière stef@genesix.org Cc : frsag@frsag.org frsag@frsag.org Objet : [FRsAG] Re: Filtrage de message au runtime
Mais pourquoi tu fais pas ce que je te dis ? :)
David
Le 28 avr. 2024 à 19:24, Stéphane Rivière stef@genesix.org a écrit :
Un petit retex de la manip, qui ne semble pas concluante...
1265 25/04/2024 18:37:33 sysctl -w kernel.printk=4 4 1 7 1266 25/04/2024 18:37:45 sysctl -w 'kernel.printk=4 4 1 7' 1268 26/04/2024 13:34:26 sysctl -w 'kernel.printk=4 4 1 4' 1274 26/04/2024 14:55:13 sysctl -w 'kernel.printk=3 3 1 3' 1275 28/04/2024 09:13:29 sysctl -w 'kernel.printk=2 2 1 2' 1276 28/04/2024 17:21:07 sysctl -w 'kernel.printk=1 1 1 1'
J'ai toujours le message...
Remis les réglages d'origine : kernel.printk = 7 4 1 7
Bonjour à toutes et tous,
J'ai, comme tout le monde j'imagine, de la brute force via ssh, qui déclenche le très agaçant message en console
"fatal: Read from socket failed: Connection reset by peer [preauth]"
Ici y'a que de la clé (et passwords invalidés) je ne peux pas filtrer sur les IP entrantes, ni changer le port 22, le plus simple me semble donc d'ignorer la chose.
J'ai googlé et ducké sans succès pour voir s'il y avait un moyen de dire au démon sshd de limiter sa prose aux fichiers de logs sans polluer la console.
man sshd ou man sshd_config ne m'ont rien dit de sympa (mais j'ai peut être raté une ligne).
Avez-vous une opinion ? Ça serait bien de faire un ménage de printemps :)
-- Stéphane Rivière Ile d'Oléron - France
Liste de diffusion du %(real_name)s https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frsag.o...http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frsag.o...http://www.frsag.org/ Ce message et toutes les pièces jointes sont confidentiels et/ou couverts par le secret professionnel et transmis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci d'en informer son émetteur ou le signaler à cpdp@cci-paris-idf.fr. La CCI Paris-IdF décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. Si l'objet de ce message est indiqué comme "privé", son contenu est sous la seule responsabilité de son auteur.
Le 29/04/2024 à 11:03, ANSART David a écrit :
Bonjour
As tu essayé le : kernel.printk = 3 4 1 7 ?
Ne présumant de rien (malgré les tests ci-dessous), j'ai tenté :)
11:10-root@i7c1:~>sysctl -w kernel.printk='3 4 1 7' kernel.printk = 3 4 1 7 11:10-root@i7c1:~>2024 Apr 29 11:15:08 i7c1 fatal: Read from socket failed: Connection reset by peer [preauth] 2024 Apr 29 11:22:45 i7c1 fatal: Read from socket failed: Connection reset by peer [preauth] 2024 Apr 29 11:42:23 i7c1 fatal: Read from socket failed: Connection reset by peer [preauth] 2024 Apr 29 12:10:32 i7c1 fatal: Read from socket failed: Connection reset by peer [preauth] 2024 Apr 29 12:16:14 i7c1 fatal: Read from socket failed: Connection reset by peer [preauth] 2024 Apr 29 13:50:16 i7c1 fatal: Read from socket failed: Connection reset by peer [preauth] 2024 Apr 29 14:36:58 i7c1 fatal: Read from socket failed: Connection reset by peer [preauth] 2024 Apr 29 15:29:27 i7c1 fatal: Read from socket failed: Connection reset by peer [preauth]
La vérité est ailleurs (C) X files
C'est quand même marrant... Debian 8 sûr, Debian 11 sûr,
Un petit retex de la manip, qui ne semble pas concluante...
1265 25/04/2024 18:37:33 sysctl -w kernel.printk=4 4 1 7 1266 25/04/2024 18:37:45 sysctl -w 'kernel.printk=4 4 1 7' 1268 26/04/2024 13:34:26 sysctl -w 'kernel.printk=4 4 1 4' 1274 26/04/2024 14:55:13 sysctl -w 'kernel.printk=3 3 1 3' 1275 28/04/2024 09:13:29 sysctl -w 'kernel.printk=2 2 1 2' 1276 28/04/2024 17:21:07 sysctl -w 'kernel.printk=1 1 1 1'
J'ai toujours le message...
Remis les réglages d'origine : kernel.printk = 7 4 1 7
(CQFD, abus en petit blanc d’Oléron pendant les HO)
De virer syslogd et mettre rsyslogd.
David
Le 29 avr. 2024 à 11:08, Stéphane Rivière stef@genesix.org a écrit :
Le 28/04/2024 à 19:32, David Ponzone a écrit :
Mais pourquoi tu fais pas ce que je te dis ? :)
T'as dis quoi ?
-- Stéphane Rivière Ile d'Oléron - France
Le 29/04/2024 à 11:10, David Ponzone a écrit :
(CQFD, abus en petit blanc d’Oléron pendant les HO)
Faudra que tu me donnes le GDH de ton mail, je me demande qui abuse de quoi ;>
Hélas hier, j'étais de permanence et j'ai bronzé devant l'écran... Hormis un court séjour sur la terrasse de la boite...
De virer syslogd et mettre rsyslogd.
Pas de syslogd. Ici c'est syslog-ng.
Et depuis Debian 12, finalement, la pieuvre a gagné et on utilise journalctl, qui a ses avantages, faut avouer...
-
ANSART David -
Arnaud Launay -
David Ponzone -
Fabien Schwebel -
Laurent Barme -
Louis G. -
Pascal PETIT -
Paul Rolland (ポール・ロラン) -
Sebastien Guilbaud -
Stéphane Rivière