Re: Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?
Le 11/07/2019 à 14:38, Olivier a écrit : Le jeu. 11 juil. 2019 à 14:04, Bernard Schoenacker < bernard.schoenac...@free.fr> a écrit : serait il possible de régler le mtu à 1492 sur la passerelle ? Sauf erreur, le MTU était déjà réglé à 1492 sur le lien ppp0, si j'en crois la sortie d' "ip link" . Evidemment, sinon l'option --clamp-mss-to-pmtu serait sans effet. ping -M do -s 1492 192.168.4.254 PING 192.168.4.254 (192.168.4.254) 1492(1520) bytes of data. ping: local error: Message too long, mtu=1492 où 192.168.4.254 est l'IP de mon serveur PPPoE (sur lequel le MTU est aussi valorisé à 1492). La valeur la plus grande pour laquelle le ping ci-dessus réussit est 1464 1464 + 8 (en-tête ICMP) + 20 (en-tête IPv4) = 1492 (le hack iptables ne change rien à cet égard). Normal, il n'affecte que les paquets TCP. Effectivement, le mot est juste : c'est un hack.
Re: Quel test unitaire illustre le problème que corrige "-j TCPMSS --clamp-mss-to-pmtu" ?
Le 11/07/2019 à 12:53, Olivier a écrit : Avec des captures Wireshark, j'ai vu que dans l'environnement en défaut, un message "ICMP Don't Fragment" était émis. Ça m'étonnerait. Ce type de message n'existe pas. Tu dois confondre avec "Fragmentation needed but DF (Don't Fragment) set". Plus spécifiquement, j'aimerai a minima, savoir quelle commande permet de détecter le problème corrigé par la cible -j TCPMSS --clamp-mss-to-pmtu de mes règles iptables ? Il n'existe pas de commande qui détecte le problème à coup sûr. Cette cible contourne un problème de gestion de MTU qui se situe dans le sens descendant : l'émetteur distant n'est pas informé que les paquets qu'il envoie sont trop gros (soit à cause d'un trou noir de MTU causé par un pontage PPPoe-PPP par exemple, soit à cause d'un routeur qui ne renvoie pas de message ICMP "Fragmentation needed" à l'émetteur, soit à cause d'un filtrage de ce message entre le routeur et l'émetteur, soit parce que l'émetteur ne tient pas compte de ce message). Envoyer un gros ping avec -M do (fragmentation interdite) est vain : le ping sera bloqué dès l'émission alors que le problème à détecter se situe en réception. Envoyer un gros ping fragmenté a plus de chances de détecter quelque chose : la cible devrait envoyer une réponse fragmentée mais en cas de problème seul le petit fragment sera reçu par l'interface PPPoE.
Re: Mise à jour jessie --> buster
Le 13/07/2019 à 01:34, Gaëtan Perrier a écrit : > Le home n'est pas suffisant. Il y a pas mal de chose dans /var /etc > /opt /usr/local ... Sur un serveur oui, sur un poste de travail pas tant que ca et c'est très facile de reprendre les fichiers dans la sauvegarde de l'ancienne version et les remettre.
Re: Mise à jour jessie --> buster
Le home n'est pas suffisant. Il y a pas mal de chose dans /var /etc /opt /usr/local ... Le 12 juillet 2019 22:15:22 GMT+02:00, hamster a écrit : >Le 12/07/2019 à 21:07, ajh-valmer a écrit : >> Install en partant de zero, il faut recréer ensuite tout son >> environnement, >> ça risque de prendre plus de temps qu'un upgrade voire 2. > >Comme déjà dit, avec une partoche /home séparée a laquelle on ne touche >pas, on retrouve son environnement tel qu'il était sans rien avoir a >faire. Il n'y a que la partie configuration système qui est a refaire, >et c'est pas grand chose : il suffit de copier les fichiers de >configuration de la version précédente. Et bien sur reinstaller les >logiciels qu'on avait, ce qui se fait en une seule commande si on en >avait sauvegardé la liste avant. -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Mise à jour jessie --> buster
Le 12/07/2019 à 21:07, ajh-valmer a écrit : > Install en partant de zero, il faut recréer ensuite tout son > environnement, > ça risque de prendre plus de temps qu'un upgrade voire 2. Comme déjà dit, avec une partoche /home séparée a laquelle on ne touche pas, on retrouve son environnement tel qu'il était sans rien avoir a faire. Il n'y a que la partie configuration système qui est a refaire, et c'est pas grand chose : il suffit de copier les fichiers de configuration de la version précédente. Et bien sur reinstaller les logiciels qu'on avait, ce qui se fait en une seule commande si on en avait sauvegardé la liste avant.
Re: Mise à jour jessie --> buster
Le ven. 12 juil. 2019 21:07, ajh-valmer a écrit : > > Le 12 juillet 2019 17:07:21 GMT+02:00, hamster a écrit : > > >Oui bien sur, mais je n'ai pas parlé de danger, juste que c'est plus > > >rapide de refaire l'install en partant de zero que de faire 2 upgrades. > > On Friday 12 July 2019 18:08:16 Gaëtan Perrier wrote: > > Plus rapide ? Pour retrouver un environnement complètement > > configuré et fonctionnel ça ne semble pas si évident que ça ... > > Mais chacun fait comme il veut. :) > > Upgrade en 2 étapes est rapide, et on retrouve son environnement. > > Install en partant de zero, il faut recréer ensuite tout son environnement, > ça risque de prendre plus de temps qu'un upgrade voire 2. > Mais il y a un risque supplémentaire de bizarreries, pouvant aller jusqu'à des bugs... surtout en enchaînant deux migrations coup sur coup. Donc configuration système propre vs reprise automatique de configuration, ça dépendra sûrement des préférences personnelles (risques & gain de temps ou lenteur & sûreté ? ). La complexité de la configuration en jeu influencera sûrement... J'avoue préférer préparer ma réinstallation sur une partition root alternative (l'ancienne config restant intacte tant que je ne suis pas sûr de la nouvelle), puis remonter ma home sur la nouvelle root, avec un point de sauvegarde, quand je pense qu'elle est correcte. Cordialement > >
Re: Mise à jour jessie --> buster
> Le 12 juillet 2019 17:07:21 GMT+02:00, hamster a écrit : > >Oui bien sur, mais je n'ai pas parlé de danger, juste que c'est plus > >rapide de refaire l'install en partant de zero que de faire 2 upgrades. On Friday 12 July 2019 18:08:16 Gaëtan Perrier wrote: > Plus rapide ? Pour retrouver un environnement complètement > configuré et fonctionnel ça ne semble pas si évident que ça ... > Mais chacun fait comme il veut. :) Upgrade en 2 étapes est rapide, et on retrouve son environnement. Install en partant de zero, il faut recréer ensuite tout son environnement, ça risque de prendre plus de temps qu'un upgrade voire 2.
Re: Mise à jour jessie --> buster
Plus rapide ? Pour retrouver un environnement complètement configuré et fonctionnel ça ne semble pas si évident que ça ... Mais chacun fait comme il veut. :) Le 12 juillet 2019 17:07:21 GMT+02:00, hamster a écrit : >Le 12/07/2019 à 14:48, ajh-valmer a écrit : >> On Friday 12 July 2019 12:33:31 hamster wrote: >>> Le 12/07/2019 à 11:56, Francois Meyer a écrit : J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il >mieux passer par Stretch ou sauter directement à Buster d'après vous ? >>> Il n'est pas du tout recommandé de sauter une version dans les mise >a >>> jour de distrib. >>> De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les >suivant >>> dans le fil, sur un poste de travail je préfère refaire l'install >plutot >>> que mettre a jour, alors a fortiori si tu a une version de retard. >> Non, on peut parfaitement upgrader sans danger > >Oui bien sur, mais je n'ai pas parlé de danger, juste que c'est plus >rapide de refaire l'install en partant de zero que de faire 2 upgrades. -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Mise à jour jessie --> buster
Le 12/07/2019 à 14:48, ajh-valmer a écrit : > On Friday 12 July 2019 12:33:31 hamster wrote: >> Le 12/07/2019 à 11:56, Francois Meyer a écrit : >>> J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il mieux >>> passer par Stretch ou sauter directement à Buster d'après vous ? >> Il n'est pas du tout recommandé de sauter une version dans les mise a >> jour de distrib. >> De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les suivant >> dans le fil, sur un poste de travail je préfère refaire l'install plutot >> que mettre a jour, alors a fortiori si tu a une version de retard. > Non, on peut parfaitement upgrader sans danger Oui bien sur, mais je n'ai pas parlé de danger, juste que c'est plus rapide de refaire l'install en partant de zero que de faire 2 upgrades.
Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée
> Noter que le serveur ici acceptait en effet la connexion par mot de > passe, ce qui est une mauvaise idée, mais, j'en était au début de sa > configuration. Entre temps, j'ai interdit la connexion par mot de > passe. > > J'étais donc justement entrain de reprendre mes différents tutoriels > pour les éprouver lors d'une installation standard. > J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison. > > Cette installation m'a permis d'être confronté à cette > problématique de > droits, pour mes propres clés, et, de ce bogue ( manque > d'informations ) > pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits. > > > il faut tenir compte ici du fait que celui qui se connecte n'est pas > forcément un utilisateur légitime à qui on a envie de fournir des > informations sur la configuration du serveur cible. > Le message concernant la clef est plus à sa place dans les logs du > serveur. Effectivement, on peut aussi le voir comme ça, pourtant, si une personne tente de se connecter avec une clé, c'est qu'il a déjà la clé ... Dès lors, si la clé est la bonne ou qu'elle ne le soit pas d'ailleurs, le programme SSH et SSHFS peut nous informer que nous en faisons un mauvais usage, au niveau des droits appliqués à la clé. Je pense que cette alerte, notamment pour les débutants, est importante. Devoir la retrouver dans les logs ne me semble pas approprié, enfin, il serait bien plus pratique, pour les débutants et même pour les confirmés, d'être informé directement en console, en cas d'erreur de droits sur la clé privée SSH.
Re: Mise à jour jessie --> buster
On Friday 12 July 2019 12:33:31 hamster wrote: > Le 12/07/2019 à 11:56, Francois Meyer a écrit : > > J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il mieux > > passer par Stretch ou sauter directement à Buster d'après vous ? > > Il n'est pas du tout recommandé de sauter une version dans les mise a > jour de distrib. > De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les suivant > dans le fil, sur un poste de travail je préfère refaire l'install plutot > que mettre a jour, alors a fortiori si tu a une version de retard. Non, on peut parfaitement upgrader sans danger, si on respecte en 2 étapes : Jessie vers Stretch et Stretch ver Buster, en le faisant en mode "recovery". Surtout, ne pas oublier de rebooter à chaque étape, en regardant les éventuels messages d'erreur. Conseil : commencer par Jessie vers Stretch, attendre un mois après la sortie de Buster (released), pour la 2ème étape (après les défauts inhérents résolus). A. Valmer
Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée
Désolé, pour le bruit, j'ai eu un coup de mou ... bien entendu nous sommes là côté client => effectivement il n'est pas normal de ne pas donner la raison exacte du refus de la clef et de la bascule sur mot de passe (ou du refus d'authentification). Cordialement Éric Dégenètais __ Éric Dégenètais Henix http://www.henix.com http://www.squashtest.org Le ven. 12 juil. 2019 à 13:54, Eric Degenetais a écrit : > > Le ven. 12 juil. 2019 13:04, G2PC a écrit : >> >> Noter que le serveur ici acceptait en effet la connexion par mot de >> passe, ce qui est une mauvaise idée, mais, j'en était au début de sa >> configuration. Entre temps, j'ai interdit la connexion par mot de passe. >> >> J'étais donc justement entrain de reprendre mes différents tutoriels >> pour les éprouver lors d'une installation standard. >> J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison. >> >> Cette installation m'a permis d'être confronté à cette problématique de >> droits, pour mes propres clés, et, de ce bogue ( manque d'informations ) >> pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits. > > Bonjour, > il faut tenir compte ici du fait que celui qui se connecte n'est pas > forcément un utilisateur légitime à qui on a envie de fournir des > informations sur la configuration du serveur cible. > Le message concernant la clef est plus à sa place dans les logs du serveur. > > Cordialement > > Éric Dégenètais
Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée
Le ven. 12 juil. 2019 13:04, G2PC a écrit : > Noter que le serveur ici acceptait en effet la connexion par mot de > passe, ce qui est une mauvaise idée, mais, j'en était au début de sa > configuration. Entre temps, j'ai interdit la connexion par mot de passe. > > J'étais donc justement entrain de reprendre mes différents tutoriels > pour les éprouver lors d'une installation standard. > J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison. > > Cette installation m'a permis d'être confronté à cette problématique de > droits, pour mes propres clés, et, de ce bogue ( manque d'informations ) > pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits. > Bonjour, il faut tenir compte ici du fait que celui qui se connecte n'est pas forcément un utilisateur légitime à qui on a envie de fournir des informations sur la configuration du serveur cible. Le message concernant la clef est plus à sa place dans les logs du serveur. Cordialement Éric Dégenètais
Re: Mise à jour jessie --> buster
Bonjour, Le 12/07/2019 à 12:33, hamster a écrit : > Il n'est pas du tout recommandé de sauter une version dans les mise a > jour de distrib. > > De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les suivant > dans le fil, sur un poste de travail je préfère refaire l'install plutot > que mettre a jour, alors a fortiori si tu a une version de retard. > Je confirme, tu seras à l'abri des mauvaises surprises. Et puis tu repars sur quelques choses de propre. -- Quentin Lejard (valde) - wiki.debian.org/QuentinLejard ⢀⣴⠾⠻⢶⣦⠀ Blog : blog.valde.fr ⣾⠁⢠⠒⠀⣿⡁ Git : framagit.org/valde ⢿⡄⠘⠷⠚⠋ twitter : @__valde__ , @DebianFrance ⠈⠳⣄ mastodon : framapiaf/@valde , @DebianFr GPG : 16FF-0108-6751-7910-D6B3-4691-DFCD-FB55-F54D-C2E2
Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée
Noter que le serveur ici acceptait en effet la connexion par mot de passe, ce qui est une mauvaise idée, mais, j'en était au début de sa configuration. Entre temps, j'ai interdit la connexion par mot de passe. J'étais donc justement entrain de reprendre mes différents tutoriels pour les éprouver lors d'une installation standard. J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison. Cette installation m'a permis d'être confronté à cette problématique de droits, pour mes propres clés, et, de ce bogue ( manque d'informations ) pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits.
Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée
>> sshfs -o allow_other, >> IdentityFile=/home/$USERLOCAL/.ssh/$SERVEUR/id_rsa_private >> $USERSERVEUR@$SERVEUR:/home/$USERSERVEUR/$FOLDER /home/$USERLOCAL/$FOLDER >> Si l'utilisateur qui se connecte est l'utilisateur root de la machine >> locale, la phrase secrète est requise lors du montage de dossiers >> partagés. > Tu es sûr que c'est la phrase secrète de la clé privée qui est demandée, et > qu'elle est ensuite utilisée ? Ça m'étonne, ça voudrait dire que ssh > tolèrerait une clé privée en 644 si c'est root qui l'utilise, ça ce serait > un bug (de ssh), j'en doute un peu, je pense qu'il demande aussi le pass > de $USERSERVEUR@$SERVEUR si c'est root qui lance la commande (et que la > clé privée est en 644, et que $SERVEUR accepte les connexions par mot de > passe, ce qui est par ailleurs une mauvaise idée). > Je comprends ton point de vue, à partir du moment où tu lui précises une clé > à utiliser il devrait le faire ou s'arrêter avec le bon message d'erreur, > mais c'est visiblement pas l'option choisie par les développeurs de sshfs > (je sais pas si c'est un choix délibéré ou un oubli, tu as bien fait de > poser la question). Merci de ta réponse ! Tu me met un doute de plus, et, à juste raison ! Je partais du principe que ce problème de message d'erreur qui indique que les droits ne sont pas corrects pour la clé privée lors de la connexion SSH, ne concernait que le simple utilisateur. J'avais donc identifié cette absence de message d'erreur, pour un simple utilisateur voulant établir une connexion SSHFS ce qui entraîne une demande de mot de passe car la clé n'est pas considérée, au lieu de demander la passphrase. Tu me dis, " Ça m'étonne, ça voudrait dire que ssh tolèrerait une clé privée en 644 si c'est root qui l'utilise, ça ce serait un bug (de ssh) " Effectivement ! Pour SSH, et, SSHFS, l'utilisateur root devrait la aussi transmettre une alerte, une information, pour rappeler que la clé privée ne possède pas les bons droits. Je pense que c'est bien un bogue de SSH et SSHFS, car, comme je te le dis, j'arrive bien à me connecter en root, sans message d'erreur, avec une clé privée en 664. Donc, j'ai bien identifié l'absence d'un message d'information sur SSHFS, et, nous avons identifié l'absence de message d'information lors de l'utilisation de root, pour une connexion SSH ou SSHFS lorsque la clé privée a les droits 664. J'ai remonté la question ici sur Debian, car, il me semblait bien que ça pouvait intéresser quelques correcteurs. Ce problème a été identifié sur une Mint Tessa 19.2 mais, je suppose que pour SSHFS, ça ne change rien. Jai ouvert la question sur le projet Github de SSHFS, mais, ce n'est pas dit que quelqu'un s'en charge. Si quelqu'un peut remonter cette information, pour vérifier ce problème pour SSH ? https://github.com/libfuse/sshfs/issues/180
Re: Mise à jour jessie --> buster
Le 12/07/2019 à 11:56, Francois Meyer a écrit : > Bonjour à tous > > J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il mieux > passer par Stretch ou sauter directement à Buster d'après vous ? Il n'est pas du tout recommandé de sauter une version dans les mise a jour de distrib. De plus, comme dit dans mon mail du 09/07/2019 à 22:51 et les suivant dans le fil, sur un poste de travail je préfère refaire l'install plutot que mettre a jour, alors a fortiori si tu a une version de retard.
Mise à jour jessie --> buster
Bonjour à tous J'ai décidé de mettre à jour ma Jessie « oldoldstable ». Vaut-il mieux passer par Stretch ou sauter directement à Buster d'après vous ? Autrement dit, est-ce que je mets "stretch" ou "stable" à la place de "jessie" dans mon source.list ? Bonne journée François
Re: openvpn privatvpn
Le 12/07/2019 à 06:02, Daniel Caillibaud a écrit : Le 11/07/19 à 18h50, MERLIN Philippe a écrit : Une analyse par Wireshark indique seulement que les DNS ne fonctionnent pas. Je ne connais pas l'origine du pb, mais tu peux installer un resolver local, c'est très léger et ça rend pas mal de services (ça évite les dns parfois menteurs des FAI, mais surtout ça marche toujours alors que suivant les FAI la résolution dns laisse parfois à désirer, et en prime tu va gagner un poil en perfs). apt install unbound et dans /etc/resolv.conf mettre nameserver 127.0.0.1 (ou bien l'indiquer dans le network manager, ou ton système de gestion de la résolution locale) Attention si c'est systemd-resolved qui gère le DNS la valeur 127.0.0.1 est à mettre dans /etc/systemd/resolved cle [Resolve] => DNS -- Daniel
