Re: Authentification ssh et PAM

[RogerT]

> Le 21 juil. 2023 à 10:26, Michel Verdier  a écrit :
> 
> Le 19 juillet 2023 RogerT a écrit :
> 
>> La validation par le gouvernement n’est en rien une garantie (sgdg…). 
> 
> Bien sûr, mais c'est quand même un plus par rapport à rien du tout.

Ça ne vaut rien du tout. Rien.

> 
>> Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
>> d’exporter en clair les pwds :
>> https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055
> Celui-là concerne le client KeePass, d'autres clients comme KeePassXC ne
> sont pas touchés. Et ça concerne le paramétrage du client pas la
> base elle-même.
> 
>> Encore une nouvelle faille en 2023 : CVE-2023-35866
>> 19/07/2023
>> https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
> 
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-35866
> Ca concerne KeePassXC mais il faut laisser la base ouverte en libre
> d'accès. A partir de là forcément n'importe quoi peut être fait sur la
> base et sans doute aussi sur le poste. Ce CVE est disputé.

C’est suffisamment grave et répété (pour d’autres gestionnaires de pwd) pour 
reconsidérer l’utilisation de ces passoires. 

« Disputed » : l’éditeur n’est pas d’accord. Ça ne veut rien dire d’autre 
(comme d’être partie à un procès dont on ignore l’issue). 
Avec des arguments pour keepass[xc] comme:
 « Oui, mais si un attaquant prend le contrôle de la machine alors il n’y a 
rien à faire » !!
 et « On ne peut pas faire de la sécurité en milieu non sûr » !!!
Ils sont fous ces gars !

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> La validation par le gouvernement n’est en rien une garantie (sgdg…). 

Bien sûr, mais c'est quand même un plus par rapport à rien du tout.

> Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
> d’exporter en clair les pwds :
> https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055
Celui-là concerne le client KeePass, d'autres clients comme KeePassXC ne
sont pas touchés. Et ça concerne le paramétrage du client pas la
base elle-même.

> Encore une nouvelle faille en 2023 : CVE-2023-35866
> 19/07/2023
> https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-35866
Ca concerne KeePassXC mais il faut laisser la base ouverte en libre
d'accès. A partir de là forcément n'importe quoi peut être fait sur la
base et sans doute aussi sur le poste. Ce CVE est disputé.

Re: Authentification ssh et PAM

[Vincent Lefevre]

On 2023-07-19 09:05:05 +0200, Michel Verdier wrote:
> Le 18 juillet 2023 roger tarani a écrit :
> > Quel est le mécanisme détaillé conduisant à l'authentification de 
> > l'utilisateur par l'hôte distant ? 
> > (la clef privée reste sur l'hôte local ; comment la clef publique et la 
> > clef privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 
> 
> La clef publique est indiquée au serveur lors de la demande de connexion.
> Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
> client avec sa clef privée.

Le chiffrage se fait avec la clé *publique* du destinataire. Mais
c'est HS ici, car il ne s'agit pas de chiffrer, mais d'authentifier,
qui est l'équivalent de vérifier une signature. Et la signature se
fait avec sa propre clé privée (et se vérifie avec la clé publique
associée).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Authentification ssh et PAM

[Jean Bernon]

Non je ne crois pas que ce soit des bijections inverses, sauf à s'entendre sur 
ce qu'on met derrière cette expression.

J'ai pioché la question du chiffrement il y a quelques années. Voici la petite 
synthèses que nous avions faite des principes de base. Elle ne répond pas à 
toutes questions de Roger. Mais elle peut aider à cadrer le débat.

Deux usages d'une paire de clés PGP dans l'échange de fichiers.

Premier usage : la paire de clés PGP permet de chiffrer / déchiffrer certains 
documents ou mails. Plus précisément, la clé publique sert au chiffrement et la 
clé privée au déchiffrement.

Deuxième usage : cette même paire de clés PGP peut aussi servir à signer 
électroniquement un mail (et à vérifier l’authenticité de la signature). Dans 
ce cas, la clé privée sert à signer et la clé publique à vérifier la signature.

Usages de GnuPG dans l'envoi d'un mail
Pourquoi ?  Qui ?   Comment ?
Chiffrement Expéditeur  Clé publique du destinataire
Déchiffrement   DestinataireClé privée du destinataire
Signature   Expéditeur  Clé privée de l'expéditeur
Vérification de la signatureDestinataireClé publique de l'expéditeur


- Mail original - 

> De: "elguero eric" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mercredi 19 Juillet 2023 18:28:24
> Objet: Re: Authentification ssh et PAM

> pour moi crypter et décrypter ne sont que des mots
> et en réalité il s'agit de deux bijections inverses
> l'une de l'autre. donc on peut aussi bien dire qu'on commence
> par décrypter un message avant de l'envoyer et
> que le récipiendaire devra alors le crypter pour retrouver
> le message original. Ou l'inverse.

> e.e.

> Le mercredi 19 juillet 2023 à 18:08:00 UTC+2, Michel Verdier
>  a écrit :

> Le 19 juillet 2023 RogerT a écrit :

> > Après vérification, et sauf erreur ou omission de ma part, je
> > regrette
> > mais en cryptographie asymétrique, seule la clef privée permet de
> > DÉchiffrer.
> > Tandis que la clef publique permet à tout le monde de chiffrer un
> > message.

> Oui tu as raison, autant pour moi, ça fait du bien de relire les
> bases de
> temps en temps. Voilà une description assez claire :
> https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[didier gaumet]

Le 20/07/2023 à 10:48, RogerT a écrit :
[...]

En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou 
carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de 
configurer account, auth, password, session) ou faut-il trouver/développer un 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

[...]

Rappel: je suis nul en sécurité donc je réponds sur ce point uniquement 
(à l'exclusion de tes autres interrogations) et ma réponse est à prendre 
avec des pincettes


- pour une clé USB (au sens large ça semble considéré comme un HSM 
aussi?) apparemment il y a le module PAM USB et la commande pamusb-conf, 
une page du wiki Debian évoque ça:

https://wiki.debian.org/pamusb

- pour les HSM plus évolués de type smartcard, de mémoire, un lien 
Redhat précédent semblait indiquer un standard PKCS#11 avec parfois des 
périphériques devant rajouter un pilote propriétaire. Le wiki Debian a 
une page sur les smartcards où il évoque deux standards, openPGP ou PKSC#11:

https://wiki.debian.org/fr/Smartcards?highlight=%28pkcs%2311%29

Re: Authentification ssh et PAM

[RogerT]

> Le 20 juil. 2023 à 10:16, didier gaumet  a écrit :
> 
> Le 20/07/2023 à 09:25, Michel Verdier a écrit :
>> Le 19 juillet 2023 didier gaumet a écrit :
>>> Pour autant que ça s'applique ici, Wikipedia a une explication d'un 
>>> mécanisme
>>> d'autentification à clés asymétriques par l'utilisation d'un double
>>> chiffrement avec les deux clés publiques (celles de chaque partie):
>>> https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification
>> En français c'est mieux :)
>> On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
>> travaillais c'est de l'authentification qui crypte avec la clef privée,
>> d'où mon inversion pour ssh.
> 
> Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on se 
> le dise ;-)
> 
> D'ailleurs c'est à se demander quel phénomène occulte et maléfique est 
> intervenu pour corrompre et distordre mon message précédent, puisque à le 
> lire soigneusement ainsi que le lien qu'il cite, on s'aperçoit que je me suis 
> encore planté (c'est pas un double chiffrement par les deux clés publiques, 
> c'est un double chiffrement par la clé privée de l'émetteur puis la clé 
> publique du destinataire ;-)
> 
> Encore une preuve qu'il ne faut pas faire aveuglément confiance à un 
> contributeur mais valider l'exactitude et la pertinence de ses propos :-)
> 
Bonjour,
Il faut toujours vérifier. 
Ça me semblait bizarre de chiffrer avec les deux clefs publiques. 

En vérifiant, j’ai redécouvert le mécanisme que je connaissais de chiffrement 
d’un fichier par l’expérience avec la clef publique du destinataire. 
C’est un mécanisme pour assurer la confidentialité. 

En revérifiant, j’ai découvert le mécanisme de chiffrement d’un (hash de) 
fichier avec la clef privée de l’expéditeur, qui permet au destinataire de 
vérifier que l’expéditeur est bien celui qui le revendique. 
C’est un mécanisme d’authentification (par signature). 

Et si on combine les deux (chiffrement par l’expéditeur avec sa clef privée 
d’un hash du fichier et avec la clef publique du fichier, alors on obtient une 
communication confidentielle et authentifiée. 

On peut donc supposer que le client ssh envoie simplement au serveur un message 
signé avec sa clef privée. Et le serveur ssh qui a une copie de la clef 
publique peut vérifier que celui qui demande la connexion est celui qu’il dit 
être (authentification). 

Échanger ici a permis de mettre les idées au clair. 
Merci. 

PS : une fois cette authentification configurée, il faut penser impérativement 
à désactiver l’authentification par pwd ou bien avoir un fail2ban installé pour 
éviter des intrusions qu’on croirait devenues impossibles sans avoir la clef 
privée si longue (RSA 2048 ou 4096).


J’ai commencé à étudier PAM et ses fichiers de configuration. 

En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou 
carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de 
configurer account, auth, password, session) ou faut-il trouver/développer un 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

Quelle est votre expérience pratique avec un HSM/une clef USB et PAM ?


PS : La question viendra ensuite de savoir quelle confiance on peut accorder à 
PAM en tant que « bus/slot/interface). Cad quelle garantie apporte-t-il de 
n’être pas un trou de sécurité ? 

Re: Authentification ssh et PAM

[Daniel Caillibaud]

Le 19/07/23 à 16:28, elguero eric  a écrit :
> pour moi crypter et décrypter ne sont que des mots

Mais les mots ont un sens ;-)

Et ici ce n'est pas le bon. En français, décrypter c'est déchiffrer un message 
dont on a pas la
clé de chiffrement (et crypter n'existe pas car ça n'a pas de sens, ça voudrait 
dire chiffrer
sans avoir la clé de chiffrement).

C'est pour ça qu'on parle de chiffrer / déchiffrer quand on code/décode un 
message en ayant la
clé.

En anglais, il n'y a pas de mot différent lorsqu'on a la clé ou pas, c'est 
toujours
encrypt/decrypt, d'où l'usage erroné très courant de crypter(sic)/décrypter en 
français.

-- 
Daniel

On tue un homme, on est un assassin.
On tue des millions d'hommes, on est un conquérant.
On les tue tous, on est un dieu.
Edmond Rostand

Re: Fwd: Authentification ssh et PAM

[didier gaumet]

Le 20/07/2023 à 09:25, Michel Verdier a écrit :

Le 19 juillet 2023 didier gaumet a écrit :


Pour autant que ça s'applique ici, Wikipedia a une explication d'un mécanisme
d'autentification à clés asymétriques par l'utilisation d'un double
chiffrement avec les deux clés publiques (celles de chaque partie):
https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification


En français c'est mieux :)
On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
travaillais c'est de l'authentification qui crypte avec la clef privée,
d'où mon inversion pour ssh.


Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on 
se le dise ;-)


D'ailleurs c'est à se demander quel phénomène occulte et maléfique est 
intervenu pour corrompre et distordre mon message précédent, puisque à 
le lire soigneusement ainsi que le lien qu'il cite, on s'aperçoit que je 
me suis encore planté (c'est pas un double chiffrement par les deux clés 
publiques, c'est un double chiffrement par la clé privée de l'émetteur 
puis la clé publique du destinataire ;-)


Encore une preuve qu'il ne faut pas faire aveuglément confiance à un 
contributeur mais valider l'exactitude et la pertinence de ses propos :-)

Re: Fwd: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 didier gaumet a écrit :

> Pour autant que ça s'applique ici, Wikipedia a une explication d'un mécanisme
> d'autentification à clés asymétriques par l'utilisation d'un double
> chiffrement avec les deux clés publiques (celles de chaque partie):
> https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification

En français c'est mieux :)
On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
travaillais c'est de l'authentification qui crypte avec la clef privée,
d'où mon inversion pour ssh.

Re: Authentification ssh et PAM

[elguero eric]

pour moi crypter et décrypter ne sont que des mots
et en réalité il s'agit de deux bijections inverses
l'une de l'autre. donc on peut aussi bien dire qu'on commence
par décrypter un message avant de l'envoyer et
que le récipiendaire devra alors le crypter pour retrouver
le message original. Ou l'inverse.

e.e.



Le mercredi 19 juillet 2023 à 18:08:00 UTC+2, Michel Verdier  a 
écrit : 

Le 19 juillet 2023 RogerT a écrit :

> Après vérification, et sauf erreur ou omission de ma part, je regrette
> mais en cryptographie asymétrique, seule la clef privée permet de
> DÉchiffrer.
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 


Oui tu as raison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 17:58, Michel Verdier  a écrit :
> 
> Le 19 juillet 2023 RogerT a écrit :
> 
 Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>>> 
>>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
>> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
>> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 
> 
> keepass est validé par le gouvernement
> https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
> D'autres gestionnaires attaqués dont j'ai entendu parlé (1password, etc) 
> avaient du
> stockage en ligne, ce n'est pas le cas de keepass. As-tu les références 
> d'articles ?


La validation par le gouvernement n’est en rien une garantie (sgdg…). 
Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
d’exporter en clair les pwds :
https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/

L’éditeur n’a pas craint d’affirmer :
« l'éditeur de KeePass estime que la base de données de mots de passe n'est pas 
censée être protégée contre un attaquant disposant déjà d'un accès local sur un 
PC. »

L’éditeur aurait aussi affirmé « on ne peut pas faire de la sécurité dans un 
environnement non sûr » !!! (j’ai lu ça ; je recherche la source). 

Encore une nouvelle faille en 2023 : CVE-2023-35866
19/07/2023
https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
L’éditeur écrit :
 "Pour l'instant, nous ne prévoyons pas de modifier radicalement le programme 
pour répondre à cette demande." - Et aussi : "La solution la plus simple pour 
contrer ce vecteur de menace est de verrouiller votre base de données avant de 
quitter votre poste de travail."


Rappel : ne quittez pas votre poste en laissant la BD déverrouillée :
https://security.stackexchange.com/questions/115086/is-it-safe-to-leave-keepass-always-opened-on-a-computer
 

On attend la révélation des autres failles ou faiblesses…

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> Après vérification, et sauf erreur ou omission de ma part, je regrette
> mais en cryptographie asymétrique, seule la clef privée permet de
> DÉchiffrer.
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 

Oui tu as raison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

>>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>> 
>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 

keepass est validé par le gouvernement
https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
D'autres gestionnaires attaqués dont j'ai entendu parlé (1password, etc) 
avaient du
stockage en ligne, ce n'est pas le cas de keepass. As-tu les références 
d'articles ?

Re: Fwd: Authentification ssh et PAM

[didier gaumet]

Pour autant que ça s'applique ici, Wikipedia a une explication d'un 
mécanisme d'autentification à clés asymétriques par l'utilisation d'un 
double chiffrement avec les deux clés publiques (celles de chaque partie):

https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification

Fwd: Authentification ssh et PAM

[RogerT]

COMPLÉMENT

J’ai approfondi ma vérification. 

J’étais parti sur le seul schéma habituel : chiffrer avec la clef publique et 
déchiffrer avec la clef privée. 

Je crois que tu voulais parler de signature numérique, où Alice (ici le client 
ssh) chiffre avec sa clef privée probablement un message fourni par Bob (ici le 
serveur ssh). Bob « déchiffre le message d’Alice » avec la clef publique. Il 
est alors certain que ça vient d’Alice et lui ouvre la porte.
C’est ça ?

Il m’échappe encore un truc que je vais explorer : je ne comprends pas comment 
Bob peut déchiffrer avec la clef publique d’Alice un message d’Alice.
J’imagine qu’il s’agit en fait seulement de « vérifier que la signature 
provient d’Alice ». 
Je fouille dans ce sens.  
Peux-tu expliquer le procédé ?

Source :
« If Alice encrypts a message using her private key and sends the encrypted 
message to Bob, then Bob can be sure that the data he receives comes from 
Alice; if Bob can decrypt the data with Alice's public key, the message must 
have been encrypted by Alice with her private key, and only Alice has Alice's 
private key. The problem is that anybody else can read the message as well 
because Alice's public key is public. Although this scenario does not allow for 
secure data communication, it does provide the basis for digital signatures. »

https://www.ibm.com/docs/en/sdk-java-technology/8?topic=processes-public-key-cryptography


Début du message transféré :

> De: RogerT 
> Date: 19 juillet 2023 à 16:59:28 UTC+2
> À: debian-user-french@lists.debian.org
> Objet: Rép. : Authentification ssh et PAM
> 
> 
> 
>>> Le 19 juil. 2023 à 16:32, Michel Verdier  a écrit :
>>> Le 19 juillet 2023 RogerT a écrit :
>>> 
>>> Pour chiffrer une phrase il suffit de la clef publique. 
>>> Pour déchiffrer une phrase il faut la clef privée.
>> 
>> Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
>> diffuses la publique à tous ceux qui doivent déchiffrer
> 
> Après vérification, et sauf erreur ou omission de ma part, je regrette mais 
> en cryptographie asymétrique, seule la clef privée permet de DÉchiffrer. 
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 
> 
> En cas d’erreur de ma part, je te/vous remercie de m’expliquer en quoi je me 
> tromperais alors que c’est le premier cas de figure ultra connu entre Alice 
> et Bob pour échanger un secret (chiffré avec la clef publique et déchiffré 
> avec la seule clef privée). 
> 
>> 
>>> Le serveur a seulement la clef publique.  
>> 
>> Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
>> lesquels tu dois te connecter) ont la publique
> Le serveur distant a la clef publique que j’y ai copié. Mais pas pour 
> déchiffrer. Voir plus haut. Sauf erreur ou omission. 
> 
> 
>>> Le client a les deux clefs. 
>>> Seul le client peut déchiffrer une phrase chiffrée.
>> 
>> Non, seul le client peut chiffrer
> 
> Tous ceux qui ont la clef publique peuvent chiffrer. 
> Et aussi celui qui a seulement la clef privée car elle permet de générer une 
> clef publique (je suppose qu’on peut chiffrer aussi avec la clef privée)
> 
>> 
>>> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
>>> la clef privée qui frappe à la porte ?
>> 
>> Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
>> client avec sa clef privée
> Toujours pas d’accord. 
> Peut-être as-tu un détail de la séquence entre client et serveur ?
> 
> 
>>>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>>>> facteurs d'authentification.
>>> Ça enlève l’intérêt d’une authentification rapide.
>>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>> 
>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 
> 
>> 
>>>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>>>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>>>> pour qu'elle soit accessible par le client.
>>> Entendu.
>>> Modulo le nom du dev /dev/sdb …
>>> Sauf à utiliser un UUID pour le device (ça se fait, je crois).
>> 
>> oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, 
>> avec
>> l'option user, et le client fait un mount du nom du répertoire que tu
>> précise. Par exemple chez moi :
>> 
>> #/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" 
>> BLOCK

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 16:32, Michel Verdier  a écrit :
> Le 19 juillet 2023 RogerT a écrit :
> 
>> Pour chiffrer une phrase il suffit de la clef publique. 
>> Pour déchiffrer une phrase il faut la clef privée.
> 
> Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
> diffuses la publique à tous ceux qui doivent déchiffrer

Après vérification, et sauf erreur ou omission de ma part, je regrette mais en 
cryptographie asymétrique, seule la clef privée permet de DÉchiffrer. 
Tandis que la clef publique permet à tout le monde de chiffrer un message. 

En cas d’erreur de ma part, je te/vous remercie de m’expliquer en quoi je me 
tromperais alors que c’est le premier cas de figure ultra connu entre Alice et 
Bob pour échanger un secret (chiffré avec la clef publique et déchiffré avec la 
seule clef privée). 

> 
>> Le serveur a seulement la clef publique.  
> 
> Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
> lesquels tu dois te connecter) ont la publique
Le serveur distant a la clef publique que j’y ai copié. Mais pas pour 
déchiffrer. Voir plus haut. Sauf erreur ou omission. 


>> Le client a les deux clefs. 
>> Seul le client peut déchiffrer une phrase chiffrée.
> 
> Non, seul le client peut chiffrer

Tous ceux qui ont la clef publique peuvent chiffrer. 
Et aussi celui qui a seulement la clef privée car elle permet de générer une 
clef publique (je suppose qu’on peut chiffrer aussi avec la clef privée)

> 
>> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
>> la clef privée qui frappe à la porte ?
> 
> Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
> client avec sa clef privée
Toujours pas d’accord. 
Peut-être as-tu un détail de la séquence entre client et serveur ?


>>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>>> facteurs d'authentification.
>> Ça enlève l’intérêt d’une authentification rapide.
>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
> 
> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd qui 
ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 

> 
>>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>>> pour qu'elle soit accessible par le client.
>> Entendu.
>> Modulo le nom du dev /dev/sdb …
>> Sauf à utiliser un UUID pour le device (ça se fait, je crois).
> 
> oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec
> l'option user, et le client fait un mount du nom du répertoire que tu
> précise. Par exemple chez moi :
> 
> #/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" 
> BLOCK_SIZE="512" TYPE="vfat" PARTUUID="f42f95e2-01"
> LABEL="CLEF"/media/usb   vfat user,noexec,noauto,noatime,lazytime 
> 0   2
> 
> PARTUUID="42711922-2694-43bd-bf1f-9d6a7fccebec" /media/backup exfat 
> user,noexec,noauto,noatime,lazytime 0       0
> 
> /dev/mmcblk0p1 /media/sd  xfs 
> user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime 
> 0 0
Ok. Merci. 


>> Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, 
>> et
>> aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans 
>> doute
>> utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification
>> LDAP).
> 
> A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les
> PAM pour établir la session. Là ce que tu travailles c'est la
> sécurisation d'une connexion ssh sur le client, donc à priori aucun
> rapport avec les PAM.
> Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès
> que tu insères une clef USB ?

Je ne sais pas trop. 
PAM offre aux applications une interface standard pour l’authentification qui 
permet de s’affranchir du mécanisme sous-jacent. Je suis en train d’étudier 
PAM. 

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> Pour chiffrer une phrase il suffit de la clef publique. 
> Pour déchiffrer une phrase il faut la clef privée. 

Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
diffuses la publique à tous ceux qui doivent déchiffrer

> Le serveur a seulement la clef publique.  

Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
lesquels tu dois te connecter) ont la publique

> Le client a les deux clefs. 
> Seul le client peut déchiffrer une phrase chiffrée. 

Non, seul le client peut chiffrer

> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
> la clef privée qui frappe à la porte ?

Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
client avec sa clef privée

>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>> facteurs d'authentification.
> Ça enlève l’intérêt d’une authentification rapide.
> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…

Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc

>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>> pour qu'elle soit accessible par le client.
> Entendu.
> Modulo le nom du dev /dev/sdb …
> Sauf à utiliser un UUID pour le device (ça se fait, je crois). 

oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec
l'option user, et le client fait un mount du nom du répertoire que tu
précise. Par exemple chez moi :

#/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" BLOCK_SIZE="512" 
TYPE="vfat" PARTUUID="f42f95e2-01"
LABEL="CLEF"/media/usb   vfat user,noexec,noauto,noatime,lazytime 0 
  2

PARTUUID="42711922-2694-43bd-bf1f-9d6a7fccebec" /media/backup exfat 
user,noexec,noauto,noatime,lazytime 0   0

/dev/mmcblk0p1 /media/sd  xfs 
user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime   
  0 0

> Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et
> aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans doute
> utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification
> LDAP).

A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les
PAM pour établir la session. Là ce que tu travailles c'est la
sécurisation d'une connexion ssh sur le client, donc à priori aucun
rapport avec les PAM.
Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès
que tu insères une clef USB ?

Re: Authentification ssh et PAM

[didier gaumet]

Le 19/07/2023 à 11:26, RogerT a écrit :

Merci beaucoup pour tes pointeurs. Je vais étudier ça.

Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection 
beaucoup plus courte que la clef elle-même 2048 bits.

En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le 
système via PAM ? (Je me dis que oui, car je crois savoir que 
l’authentification par LDAP passe par PAM).
Qui a de l’expérience sur utiliser un HSM via ou sans PAM ?
Merci.


rappel d'avertissement: je suis une tanche en réseau et sécurité, donc 
ne te fie surtout pas à mes suppositions sans te référer à des personnes 
dont tu estimes qu'elles ont une expertise valable et sans étudier avec 
esprit critique les solutions possibles.


J'ai l'*impression* (je suis une tanche) que les bonnes pratiques 
actuellement recommandent l'emploi de PAM au sein d'un groupe de 
solutions lorsqu'il s'agit d'un contexte réseau global (exemple: réseau 
d'une grosse entreprise, par opposition à un réseau d'un particulier 
offrant un unique service quelconque sans que les conséquences soient 
catastrophiques si il y a intrusion dans le réseau) ayant des impératifs 
de sécurité.


Mais j'ai l'*impression* qu'il est possible, même pour un administrateur 
réseau consciencieux et prudent, d'avoir laissé des trous dans sa config 
PAM qui permettent le contournement de PAM.


Donc j'ai l'*impression* aussi qu'il doit être possible de 
volontairement court-circuiter PAM pour employer un HSM, probablement 
dans un but de simplification


Mais j'ai aussi l'*impression* que ce serait potentiellement 
contre-productif puisque le but de PAM me semblant plus ou moins de 
border la sécurité d'accès en général et l'emploi d'un HSM représentant 
un cas d'emploi, ce serait alors potentiellement bizarre de vouloir 
contourner PAM par facilité.


Tu noteras que ça fait beaucoup d'impressions et qu'il ne serait pas 
sage de s'appuyer trop fort là-dessus ;-)


Si tu me permets une suggestion (amicale et d'un ignare du sujet), la 
réponse que t'a faite Michel Verdier par ailleurs pourrait laisser 
penser que comme moi, il s'interroge sur la clarté de tes objectifs 
(qu'est-ce que tu veux faire exactement?), et peut-être pourrais-tu 
essayer de débroussailler le but à atteindre sans dans un premier temps 
envisager les moyens à mettre en oeuvre (ici un HSM) car ça influe sur 
la réflexion


:-)

Re: Authentification ssh et PAM

[RogerT]

Merci beaucoup pour tes pointeurs. Je vais étudier ça.

Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection 
beaucoup plus courte que la clef elle-même 2048 bits.

En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le 
système via PAM ? (Je me dis que oui, car je crois savoir que 
l’authentification par LDAP passe par PAM).  
Qui a de l’expérience sur utiliser un HSM via ou sans PAM ?
Merci. 


> Le 19 juil. 2023 à 10:08, didier gaumet  a écrit :
> 
> je n'y connais rien mais tu peux éventuellement consulter ce qui suit:
> 
> - sur le fonctionnement général de PAM: la vieille doc de kernel.org (The 
> Linux-PAM System Administrators' Guide) n'est plus semble-t-il disponible sur 
> le site d'origine mais on la dtouve encore ailleurs:
> https://beausanders.org/linux_shared_files/Linux-PAM_System_Administrators_Guide.pdf
> la mage man de PAM(8) peut aussi être consultée
> 
> - sur le principe général (avec diagrammes, plus visuels) de l'emploi des 
> smartcards (sous-type de HSM); RedHat propose cette doc:
> https://www.redhat.com/en/blog/consistent-pkcs-11-support-red-hat-enterprise-linux-8
> 
> - sur la configuration particulière nécessaire à cet usage en liaison avec 
> des applis/serveurs, Red Hat propose cette doc:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening
> 

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 09:05, Michel Verdier  a écrit :
> Le 18 juillet 2023 roger tarani a écrit :
> 
>> Quel est le mécanisme détaillé conduisant à l'authentification de 
>> l'utilisateur par l'hôte distant ? 
>> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
>> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )
> 
> La clef publique est indiquée au serveur lors de la demande de connexion.
> Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
> client avec sa clef privée.

Je ne comprends pas. 
Pour chiffrer une phrase il suffit de la clef publique. 
Pour déchiffrer une phrase il faut la clef privée. 
Le serveur a seulement la clef publique.  
Le client a les deux clefs. 
Seul le client peut déchiffrer une phrase chiffrée. 
Comment fait le serveur ssh pour savoir que c’est bien le détenteur de la clef 
privée qui frappe à la porte ?
Je ne vois que ça : le serveur chiffre une phrase et l’envoie au client qui lui 
retourne déchiffrée. Il compare et constate si le client a su déchiffrer. C’est 
ça ?

>> Stocker la clef privée localement avec pour seule protection des droits 600 
>> me semble léger même si c'est habituel.
> 
> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
> facteurs d'authentification.
Ça enlève l’intérêt d’une authentification rapide.
Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…

> 
>> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur 
>> une
>> clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
>> sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le 
>> système
> 
> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
> pour qu'elle soit accessible par le client.
Entendu.
Modulo le nom du dev /dev/sdb …
Sauf à utiliser un UUID pour le device (ça se fait, je crois). 

> 
>> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>>  
>> 
>> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte 
>> local et le HSM afin de réaliser une authentification ssh ? 
>> Comment faut-il faire ?
> 
> Je ne comprend pas ce que tu cherches à faire ? Tu veux qu'une
> authentification PAM passe par ssh et pas par le login habituel ?
Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et 
aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans doute 
utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification 
LDAP).

Re: Authentification ssh et PAM

[didier gaumet]

je n'y connais rien mais tu peux éventuellement consulter ce qui suit:

- sur le fonctionnement général de PAM: la vieille doc de kernel.org 
(The Linux-PAM System Administrators' Guide) n'est plus semble-t-il 
disponible sur le site d'origine mais on la dtouve encore ailleurs:

https://beausanders.org/linux_shared_files/Linux-PAM_System_Administrators_Guide.pdf
la mage man de PAM(8) peut aussi être consultée

- sur le principe général (avec diagrammes, plus visuels) de l'emploi 
des smartcards (sous-type de HSM); RedHat propose cette doc:

https://www.redhat.com/en/blog/consistent-pkcs-11-support-red-hat-enterprise-linux-8

- sur la configuration particulière nécessaire à cet usage en liaison 
avec des applis/serveurs, Red Hat propose cette doc:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening

Re: Authentification ssh et PAM

[Michel Verdier]

Le 18 juillet 2023 roger tarani a écrit :

> Quel est le mécanisme détaillé conduisant à l'authentification de 
> l'utilisateur par l'hôte distant ? 
> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
> privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 

La clef publique est indiquée au serveur lors de la demande de connexion.
Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
client avec sa clef privée.

> Stocker la clef privée localement avec pour seule protection des droits 600 
> me semble léger même si c'est habituel. 

L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
facteurs d'authentification.

> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une
> clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
> sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le système

sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
pour qu'elle soit accessible par le client.

> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>  
>
> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte 
> local et le HSM afin de réaliser une authentification ssh ? 
> Comment faut-il faire ? 

Je ne comprend pas ce que tu cherches à faire ? Tu veux qu'une
authentification PAM passe par ssh et pas par le login habituel ?

Re: Authentification ssh et PAM

[RogerT]

Merci. 
Je connais l’usage.

Je voudrais savoir comment fonctionne le mécanisme d’authentification par clefs 
asymétriques permettant de donner l’accès à l’hôte distant. Qui fait quoi. 

Et surtout comment procéder pour utiliser un HSM ou une clef USB où sera 
stockée la clef privée. Et aussi savoir si on doit utiliser PAM, et comment.



> Le 19 juil. 2023 à 00:00, ajh-valmer  a écrit :
> 
> Il suffit de taper 3 mots dans un moteur de recherche :
> www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
> :-)
> 
>> On Tuesday 18 July 2023 18:16:21 roger.tar...@free.fr wrote:
>> Un utilisateur dispose d'une clef ssh privée et d'une clef publique 
>> rangés dans ~/.ssh/ , avec des droits 600.  
>> S'il a copié la clef publique sur un serveur distant, l'agent local
>> saura "lier la clef publique et la privée" pour lui donner accès à l'hôte
>> distant sans besoin de saisir id et pwd.   
>> Classique. 
>> Quel est le mécanisme détaillé conduisant à l'authentification de
>> l'utilisateur par l'hôte distant ?  
>> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef
>> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )  
>> Stocker la clef privée localement avec pour seule protection des droits 600
>> me semble léger même si c'est habituel.  
>> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur
>> une clef flash déconnectée du réseau (avec ou sans chiffrement), soit
>> carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée
>> par le système ?
>> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>>  
>> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte
>> local et le HSM afin de réaliser une authentification ssh ?  
>> Comment faut-il faire ?
> 

Re: Authentification ssh et PAM

[ajh-valmer]

Il suffit de taper 3 mots dans un moteur de recherche :
www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
:-)

On Tuesday 18 July 2023 18:16:21 roger.tar...@free.fr wrote:
> Un utilisateur dispose d'une clef ssh privée et d'une clef publique 
> rangés dans ~/.ssh/ , avec des droits 600.  
> S'il a copié la clef publique sur un serveur distant, l'agent local
> saura "lier la clef publique et la privée" pour lui donner accès à l'hôte
> distant sans besoin de saisir id et pwd.   
> Classique. 
> Quel est le mécanisme détaillé conduisant à l'authentification de
> l'utilisateur par l'hôte distant ?  
> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef
> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )  
> Stocker la clef privée localement avec pour seule protection des droits 600
> me semble léger même si c'est habituel.  
> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur
> une clef flash déconnectée du réseau (avec ou sans chiffrement), soit
> carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée
> par le système ?
> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
> 
> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte
> local et le HSM afin de réaliser une authentification ssh ?  
> Comment faut-il faire ?

Authentification ssh et PAM

[roger . tarani]

Bonjour, 

Un utilisateur dispose d'une clef ssh privée et d'une clef publique rangés dans 
~/.ssh/ , avec des droits 600. 
S'il a copié la clef publique sur un serveur distant, l'agent local saura "lier 
la clef publique et la privée" pour lui donner accès à l'hôte distant sans 
besoin de saisir id et pwd. 
Classique. 

Quel est le mécanisme détaillé conduisant à l'authentification de l'utilisateur 
par l'hôte distant ? 
(la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 

Stocker la clef privée localement avec pour seule protection des droits 600 me 
semble léger même si c'est habituel. 

Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une 
clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément sur 
un HSM, comment dois-je procéder pour qu'elle soit utilisée par le système ? 

En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
 

Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte local 
et le HSM afin de réaliser une authentification ssh ? 
Comment faut-il faire ? 

Merci. 

Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[Sébastien Dinot]

Basile Starynkevitch a écrit :
> C'était ma faute, j'avais git clone-é en
> https://github.com/RefPerSys/RefPerSys au lieu de
> ssh://github.com/RefPerSys/RefPerSys

Voilà, tout s'explique. ;)

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[Basile Starynkevitch]

On 5/7/23 21:13, Sébastien Dinot wrote:

Bonsoir Basile,

Basile Starynkevitch a écrit :

Bien sûr, j'ai des clef SSH

Mais github demande maintenant un mot de passe à chaque git push.

Pourrais-tu nous expliquer exactement ce qui se passe, en nous
fournissant des copies des messages affichés par Git ? Je viens de faire
un test rapide et je ne reproduis pas ce problème (j'étais certain du
résultat, car un changement à ce niveau aurait un impact ravageur, mais
j'ai voulu le vérifier parce qu'il faut toujours vérifier ce qu'on croit
savoir).

Le mot de passe qui t'est demandé est-il celui de ta clé SSH ou celui de
ton compte Github ? Dans le premier cas, il faut vérifier l'absence de
problème au niveau de l'agent SSH ou des droits sur le répertoire ~/.ssh
ou les fichiers contenant les clés. Dans le second cas, c'est que l'uri
du dépôt distant est celle correspondant au protocole HTTPS et non au
protocole SSH.


Connaissez vous une alternative en Europe? (je suis prêt à payer une
douzaine d'€ par mois, si nécessaire).



C'était ma faute, j'avais git clone-é en 
https://github.com/RefPerSys/RefPerSys au lieu de 
ssh://github.com/RefPerSys/RefPerSys



(pour lequel je cherche encore des utilisateurs et contributeurs, voir 
aussi http://refpersys.org/ )



Librement

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Re : Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[Sébastien Dinot]

Hugues Larrive a écrit :
> J'ai déjà essayé ça et je peux vous dire qu'il faut un Serveur avec un
> grand 'S'. Ce truc est littéralement obèse, ils disent 4Go de RAM pour
> 500 utilisateurs mais en fait il "mange" déjà les 4Go avant même la
> création du premier utilisateur.

Je le confirme, le « talon » de Gitlab en RAM est conséquent et cette
consommation fait un bond dès qu'on commence à le faire travailler un
peu. Mais ensuite, l'augmentation de la RAM est très raisonnable lorsque
le nombre de projets ou d'utilisateurs augmente.

Sur mon serveur auto-hébergé, qui était doté de 16 Go de RAM, je faisais
cohabiter sans problème Gitlab, SonarQube, Piwigo, Roundcube, Nut et une
brochette d'autres applications. Le tout consommait autour des 12 Go.

Ce n'est que lorsque j'ai mis sur ce serveur un exécuteur Gitlab Runner
à disposition d'un projet libre gourmand en ressources que j'ai dû doper
la machine et passer à 32 Go (les jobs de CI de ce projet libre
consommaient jusqu'à 10 Go à eux seuls).

> Il faut donc plusieurs projets et des centaines d'utilisateurs pour
> amortir une instance.

Pas forcément. Dans mon cas, ma priorité est d'auto-héberger mes
services et de disposer notamment de mes propres instances de mes outils
de développement.

> À l'époque je m'étais rabattu sur gitea...

Gitea est une alternative à considérer et, pour l'instant, encore
réellement libre (Gitlab étant open core). Mais sur le plan fonctionnel,
on ne peut vraiment pas comparer Gitlab et Gitea, même avec l'apparition
récente de Gitea Actions.

Sébastien


-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[Sébastien Dinot]

Bonsoir Basile,

Basile Starynkevitch a écrit :
> Bien sûr, j'ai des clef SSH
> 
> Mais github demande maintenant un mot de passe à chaque git push.

Pourrais-tu nous expliquer exactement ce qui se passe, en nous
fournissant des copies des messages affichés par Git ? Je viens de faire
un test rapide et je ne reproduis pas ce problème (j'étais certain du
résultat, car un changement à ce niveau aurait un impact ravageur, mais
j'ai voulu le vérifier parce qu'il faut toujours vérifier ce qu'on croit
savoir).

Le mot de passe qui t'est demandé est-il celui de ta clé SSH ou celui de
ton compte Github ? Dans le premier cas, il faut vérifier l'absence de
problème au niveau de l'agent SSH ou des droits sur le répertoire ~/.ssh
ou les fichiers contenant les clés. Dans le second cas, c'est que l'uri
du dépôt distant est celle correspondant au protocole HTTPS et non au
protocole SSH.

> Connaissez vous une alternative en Europe? (je suis prêt à payer une
> douzaine d'€ par mois, si nécessaire).

Beaucoup de liens t'ont déjà été donnés. Et si je ne porte guère Github
dans mon cœur, il me semble bien plus simple de comprendre l'origine
véritable de ton problème que de migrer vers un autre hébergeur.

A++, Sébastien


-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re : Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[Hugues Larrive]

Bonjour,

--- Original Message ---
Le dimanche 7 mai 2023 à 14:00, benoit  a écrit :

> Le top serait d'installer sa propre instance de Gitlab sur un serveur
> 


J'ai déjà essayé ça et je peux vous dire qu'il faut un Serveur avec un grand 
'S'. Ce truc est littéralement obèse, ils disent 4Go de RAM pour 500 
utilisateurs mais en fait il "mange" déjà les 4Go avant même la création du 
premier utilisateur. Il faut donc plusieurs projets et des centaines 
d'utilisateurs pour amortir une instance. À l'époque je m'étais rabattu sur 
gitea...

@+
Hugues

publickey - hlarrive@pm.me - 0xE9429B87.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re : Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[benoit]

Le samedi 6 mai 2023 à 13:26, NoSpam  a écrit :



>
>
> Framagit
>

+1


Framagit est une instance de Gitlab.
Mais Framasoft essaye de rendre les gens indépendants.

Le top serait d'installer sa propre instance de Gitlab sur un serveur

https://framacloud.org/fr/cultiver-son-jardin/gitlab.html

--
Benoit

Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[Michel Verdier]

Le 6 mai 2023 Jean-Marc a écrit :

> À Bruxelles, il y a https://www.domainepublic.net.
>
> Tu peux ouvrir un compte avec plein de services pour 30€ par an.

Et en France il y a le collectif https://www.chatons.org (issu de
Framasoft) qui héberge plusieurs fournisseurs pour ce service :

https://www.chatons.org/en/search/by-service?service_type_target_id=131_alternatives_aux_services_target_id=All_software_target_id=All_is_shared_value=All=

Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[Jean-Marc]

salut Basile,

Le 6/05/23 à 10:18, Basile Starynkevitch a écrit :

Bonjour la liste


Sur mon temps libre je développe avec d'autres le moteur d'inférences 
RefPerSys (en logiciel libre GPLv3+, pour Debian ou autre Linux): voir 
http://refpersys.org/ et code en https://github.com/RefPerSys/RefPerSys


Bien sûr, j'ai des clef SSH

Mais github demande maintenant un mot de passe à chaque git push.


Connaissez vous une alternative en Europe? (je suis prêt à payer une 
douzaine d'€ par mois, si nécessaire).



Il y a pas mal de fournisseurs de services locaux un peu partout.

À Bruxelles, il y a https://www.domainepublic.net.

Tu peux ouvrir un compte avec plein de services pour 30€ par an.

Ou utiliser certains services en accès libre :
https://www.domainepublic.net/Nos-Services.html

Bon week-end.

--
Jean-Marc


OpenPGP_signature
Description: OpenPGP digital signature

Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[François TOURDE]

Le 19483ième jour après Epoch,
Basile Starynkevitch écrivait:

> Mais github demande maintenant un mot de passe à chaque git push.

Je n'ai pas ce comportement de mon côté. C'est assez étonnant. Tu as
bien g...@github.com:RefPerSys/RefPerSys.git dans le fichier .git/config
pour l'URL du repo ?

Est-ce le mot de passe de ta clef SSH ou bien celui de ton compte github
?

Mes 2¢

Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[NoSpam]

Bonjour

Le 06/05/2023 à 10:18, Basile Starynkevitch a écrit :

Bonjour la liste


Sur mon temps libre je développe avec d'autres le moteur d'inférences 
RefPerSys (en logiciel libre GPLv3+, pour Debian ou autre Linux): voir 
http://refpersys.org/ et code en https://github.com/RefPerSys/RefPerSys


Bien sûr, j'ai des clef SSH

Mais github demande maintenant un mot de passe à chaque git push.


Connaissez vous une alternative en Europe? (je suis prêt à payer une 
douzaine d'€ par mois, si nécessaire).


Framagit

--
Daniel

Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[Basile Starynkevitch]

On 5/6/23 12:33, Dethegeek wrote:

Bonjour

Je me sers quotidiennement de GitHub avec une clé wsh. Je suis en 
France, et je n'ai jamais besoin de mot de passe; la clé privée 
suffit. Je te donne tout a l'heure les infos pour configurer tout ça.


Je suppose que tu as déjà déposé ta clé publique dans ton profil ?



Oui.

https://github.com/bstarynk/


Comment créer la clef wsh?


(j'en  ai en ssh)




Le sam. 6 mai 2023 à 10:18, Basile Starynkevitch 
 a écrit :


Bonjour la liste


Sur mon temps libre je développe avec d'autres le moteur d'inférences
RefPerSys (en logiciel libre GPLv3+, pour Debian ou autre Linux):
voir
http://refpersys.org/ et code en
https://github.com/RefPerSys/RefPerSys

Bien sûr, j'ai des clef SSH

Mais github demande maintenant un mot de passe à chaque git push.


Connaissez vous une alternative en Europe? (je suis prêt à payer une
douzaine d'€ par mois, si nécessaire).

Avec les fichiers executables, RefPerSys consomme actuellement
environ
250Mo d'espace disque.


Librement



-- 
Basile Starynkevitch                  

(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ <http://starynkevitch.net/Basile/>


--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[didier gaumet]

Le 06/05/2023 à 10:18, Basile Starynkevitch a écrit :

Bonjour la liste


Sur mon temps libre je développe avec d'autres le moteur d'inférences 
RefPerSys (en logiciel libre GPLv3+, pour Debian ou autre Linux): voir 
http://refpersys.org/ et code en https://github.com/RefPerSys/RefPerSys


Bien sûr, j'ai des clef SSH

Mais github demande maintenant un mot de passe à chaque git push.


Connaissez vous une alternative en Europe? (je suis prêt à payer une 
douzaine d'€ par mois, si nécessaire).


Avec les fichiers executables, RefPerSys consomme actuellement environ 
250Mo d'espace disque.



Librement





Bonjour,

Avertissement: je n'utilise pas ce genre de service donc ma connaissance 
du contexte est pour le moins, euh... perfectible ;-)


une recherche sur internet concernant les alternatives européennes à 
Github ramène à boire et à manger, c'est-à-dire qu'il y a un pourcentage 
important de hit-parades ("nos 5/10/15/20 meilleures solutions pour... 
(rapporter du fric à notre site)") plus ou moins objectifs et pertinents.
Je n'en ai (brièvement) relevé qu'un, qui ait l'air un peu sérieux (sur 
le côté alternative européenne, je n'ai pas d'info sur la nécessité de 
s'identifier pour faire un push, à creuser):

https://european-alternatives.eu/alternative-to/github

il y a aussi un comparateur sur Wikipedia qui ne t'apportera pas la 
réponse à ta question mais pourrait t'apporter des pistes:

https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities

utiliser github avec clef ssh et sans mot de passe (ou alternative européenne)

[Basile Starynkevitch]

Bonjour la liste


Sur mon temps libre je développe avec d'autres le moteur d'inférences 
RefPerSys (en logiciel libre GPLv3+, pour Debian ou autre Linux): voir 
http://refpersys.org/ et code en https://github.com/RefPerSys/RefPerSys


Bien sûr, j'ai des clef SSH

Mais github demande maintenant un mot de passe à chaque git push.


Connaissez vous une alternative en Europe? (je suis prêt à payer une 
douzaine d'€ par mois, si nécessaire).


Avec les fichiers executables, RefPerSys consomme actuellement environ 
250Mo d'espace disque.



Librement



--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re : Re: SSH PasswordAuthentication à no

[benoit]

Ben oui, il y a plein de doc en plus :
https://duckduckgo.com/?q=SSH+key++authentication+with+LDAP=ffab=web

Avec gratitude,

--
Benoit




Envoyé avec la messagerie sécurisée ProtonMail.
--- Original Message ---
Le lundi 11 avril 2022 à 16:57, Roberto C. Sánchez  a écrit 
:


> On Mon, Apr 11, 2022 at 01:16:41PM +, benoit wrote:
>
> > Bonjour à tous,
> > Si sur le serveur SSH on a désactivé l’authentification par mot de passe,
> > comment fait-on pour ajouter les clés de nouveaux utilisateurs ?
> > Une fois qu'on à configuré ssh avec
> > PasswordAuthentication no
> > On ne sait plus ajouter de nouveaux utilisateur avec
> > ssh-keygen
> > ssh-copy-id toto@nom-machine
> > On doit à chaque nouvel ajout de clé, supprimer
> > PasswordAuthentication no
> > redémarrer le serveur,
> > Ajouter la clé via un nouveau client, ajouter la ligne
> > PasswordAuthentication no
> > Redémarrer ssh ?
> > Il y a-il une procédure plus simple ?
> > Merci d'avance.
>
>
> Dans ce cas, il faut donner aux utilisateurs une autre manière d'ajouter
> les clés. Par exemple, GitHub a une interface web et l'utilisateur peut
> faire un copier-coller de sa clé pour pouvoir acceder au service sans
> mot de passe pour les operations CLI git. LDAP peut aussi servir de
> manière d'utilisateurs garder ses clés. Le service ssh peut être
> configuré pour obtenir des clés de LDAP.
>
> Salut,
>
> -Roberto
> --
> Roberto C. Sánchez

Re: SSH PasswordAuthentication à no

[Roberto C . Sánchez]

On Mon, Apr 11, 2022 at 01:16:41PM +, benoit wrote:
>Bonjour à tous,
>Si sur le serveur SSH on a désactivé l’authentification par mot de passe,
>comment fait-on pour ajouter les clés de nouveaux utilisateurs ?
>Une fois qu'on à configuré ssh avec
>PasswordAuthentication no
>On ne sait plus ajouter de nouveaux utilisateur avec
>    ssh-keygen
>ssh-copy-id toto@nom-machine
>On doit à chaque nouvel ajout de clé, supprimer
>PasswordAuthentication no
>redémarrer le serveur,
>Ajouter la clé via un nouveau client, ajouter la ligne
>PasswordAuthentication no
>Redémarrer ssh ?
>Il y a-il une procédure plus simple ?
>Merci d'avance.

Dans ce cas, il faut donner aux utilisateurs une autre manière d'ajouter
les clés.  Par exemple, GitHub a une interface web et l'utilisateur peut
faire un copier-coller de sa clé pour pouvoir acceder au service sans
mot de passe pour les operations CLI git.  LDAP peut aussi servir de
manière d'utilisateurs garder ses clés.  Le service ssh peut être
configuré pour obtenir des clés de LDAP.

Salut,

-Roberto
-- 
Roberto C. Sánchez

SSH PasswordAuthentication à no

[benoit]

Bonjour à tous,

Si sur le serveur SSH on a désactivé l’authentification par mot de passe, 
comment fait-on pour ajouter les clés de nouveaux utilisateurs ?

Une fois qu'on à configuré ssh avec
PasswordAuthentication no

On ne sait plus ajouter de nouveaux utilisateur avec

ssh-keygen
ssh-copy-id toto@nom-machine

On doit à chaque nouvel ajout de clé, supprimer
PasswordAuthentication no
redémarrer le serveur,

Ajouter la clé via un nouveau client, ajouter la ligne
PasswordAuthentication no
Redémarrer ssh ?

Il y a-il une procédure plus simple ?

Merci d'avance.

--
Benoit

Envoyé avec la messagerie sécurisée [ProtonMail](https://protonmail.com/).

Re: [HS] Possible attaque SSH

[Dethegeek]

Bonjour

De mon expérience avec fail2banet ssh, dans une situation similaire (NAT
derrière une box) les IP des attaquants sont celles venant de l'extérieur.
Donc si dans les logs les ip appartiennent au réseau local, c'est que
l'attaquant s'y trouve, ou bien utilise une machine locale pour effectuer
ses attaques.

Idem que précédemment, fail2ban enregistre de nombreuses attaques par heure
en permanence.

Le mar. 22 févr. 2022 à 12:29, Belaïd  a écrit :

> Bonjour,
>
> C'est possible que ça vienne de l'extérieur (a l'époque ca pouvait être
> une attaque par IP spoofing/paquet martien). Mais ça ne ce fait plus trop
> de nos jours , les routeurs/firewall savent gérer cela
>
> Le mar. 22 févr. 2022 à 11:50, Sil  a écrit :
>
>> Le 22/02/2022 à 09:27, Sil a écrit :
>> > /var/log/auth.log.2.gz:Feb 7 09:34:58 monserveur sshd[]:
>> > Disconnected from invalid user Admin 192.168.X.X port  [preauth]
>>
>> Mais est-ce que l'IP du fichier log peut provenir de l’extérieur ? Ou
>> est-ce impossible ?
>>
>> Est-il possible de différencier les connexions nattées de la box et
>> celles du réseau local ?
>>
>> Merci
>>
>> Sil
>>
>>

Re: [HS] Possible attaque SSH

[Belaïd]

Bonjour,

C'est possible que ça vienne de l'extérieur (a l'époque ca pouvait être une
attaque par IP spoofing/paquet martien). Mais ça ne ce fait plus trop de
nos jours , les routeurs/firewall savent gérer cela

Le mar. 22 févr. 2022 à 11:50, Sil  a écrit :

> Le 22/02/2022 à 09:27, Sil a écrit :
> > /var/log/auth.log.2.gz:Feb 7 09:34:58 monserveur sshd[]:
> > Disconnected from invalid user Admin 192.168.X.X port  [preauth]
>
> Mais est-ce que l'IP du fichier log peut provenir de l’extérieur ? Ou
> est-ce impossible ?
>
> Est-il possible de différencier les connexions nattées de la box et
> celles du réseau local ?
>
> Merci
>
> Sil
>
>

Re: [HS] Possible attaque SSH

[ajh-valmer]

On Tuesday 22 February 2022 09:27:46 Sil wrote:
> Bonjour la liste,
> Pourriez-vous m'enlever un doute... sur un réseau local derrière une 
> box, j'ai des postes w$ DHCP et un serveur Debian stable à jour. Ce 
> serveur est accessible via SSH sur le réseau local via le port classique 
> et depuis l’extérieur sur un autre port via le NAT de la box. Seule 
> l’authentification par clé est autorisée.
> J'ai un utilisateur qui s'est plaint d'avoir été banni par Fail2ban. 
> Après quelques recherches dans les logs, j'ai trouvé plusieurs 
> tentatives de connexions SSH via des adresses locales.
> Un exemple de log :
> /var/log/auth.log.2.gz:Feb  7 09:34:58 monserveur sshd[]: 
> Disconnected from invalid user Admin 192.168.X.X port  [preauth]
> Est-il possible que l'attaque vienne quand même de l’extérieur ? Ou 
> faut-il suspecter les postes w$ ?

Hello,

J'ai un serveur, il ne faut pas trop s'inquiéter du fichier "/var/log/auth.log",
ce sont des milliers de tentatives de connexion / jour, sans résultats,
(souvent par une méthode automatique) si le serveur possède
les outils classiques de protection, failban, firewall, connexions que par
clés SSH (publique et privée)...

A. Valmer

Re: [HS] Possible attaque SSH

[Sil]

Le 22/02/2022 à 09:27, Sil a écrit :
/var/log/auth.log.2.gz:Feb 7 09:34:58 monserveur sshd[]: 
Disconnected from invalid user Admin 192.168.X.X port  [preauth]


Mais est-ce que l'IP du fichier log peut provenir de l’extérieur ? Ou 
est-ce impossible ?


Est-il possible de différencier les connexions nattées de la box et 
celles du réseau local ?


Merci

Sil

Re: [HS] Possible attaque SSH

[BERTRAND Joël]

Sil a écrit :
> Bonjour la liste,
> 
> Pourriez-vous m'enlever un doute... sur un réseau local derrière une
> box, j'ai des postes w$ DHCP et un serveur Debian stable à jour. Ce
> serveur est accessible via SSH sur le réseau local via le port classique
> et depuis l’extérieur sur un autre port via le NAT de la box. Seule
> l’authentification par clé est autorisée.
> 
> J'ai un utilisateur qui s'est plaint d'avoir été banni par Fail2ban.
> Après quelques recherches dans les logs, j'ai trouvé plusieurs
> tentatives de connexions SSH via des adresses locales.
> 
> Un exemple de log :
> 
> /var/log/auth.log.2.gz:Feb  7 09:34:58 monserveur sshd[]:
> Disconnected from invalid user Admin 192.168.X.X port  [preauth]
> 
> Est-il possible que l'attaque vienne quand même de l’extérieur ? Ou
> faut-il suspecter les postes w$ ?
> 
> Par avance merci
Bonjour,

Par expérience, suspecter les postes Windows. Il y a quinze ans, j'ai
râlé avec un client qui laissait ses utilisateurs sur MSN (fallait bien
qu'ils s'occupent !) et les machines Windows ont servi de relais à des
attaques de l'extérieur malgré un firewall entrant (on m'avait interdit
le firewall sortant). Un lundi matin, je me suis fait enguirlander parce
que le serveur principal avait été attaqué (mais sans accès root,
c'était une machine sparc64).

Cordialement,

JKB

[HS] Possible attaque SSH

[Sil]

Bonjour la liste,

Pourriez-vous m'enlever un doute... sur un réseau local derrière une 
box, j'ai des postes w$ DHCP et un serveur Debian stable à jour. Ce 
serveur est accessible via SSH sur le réseau local via le port classique 
et depuis l’extérieur sur un autre port via le NAT de la box. Seule 
l’authentification par clé est autorisée.


J'ai un utilisateur qui s'est plaint d'avoir été banni par Fail2ban. 
Après quelques recherches dans les logs, j'ai trouvé plusieurs 
tentatives de connexions SSH via des adresses locales.


Un exemple de log :

/var/log/auth.log.2.gz:Feb  7 09:34:58 monserveur sshd[]: 
Disconnected from invalid user Admin 192.168.X.X port  [preauth]


Est-il possible que l'attaque vienne quand même de l’extérieur ? Ou 
faut-il suspecter les postes w$ ?


Par avance merci

Sil

Re: Truc louche avec ssh

[BERTRAND Joël]

G2PC a écrit :
> A tout hasard, tu as assez de ram ?
> Si le fichier est trop lourd, ça peut jouer ?
> Sinon, tu peux tenter de gérer les tailles des fichiers de logs pour
> n'avoir que 1 ou 5Mo max par fichier ?
> Le tail pourrait alors peut être ne plus tuer la connexion ?

Je pense que de ce côté là, c'est bon: 32 Go de part et d'autre et des
fichiers logs tout à fait raisonnables.

Re: Truc louche avec ssh

[G2PC]

A tout hasard, tu as assez de ram ?
Si le fichier est trop lourd, ça peut jouer ?
Sinon, tu peux tenter de gérer les tailles des fichiers de logs pour
n'avoir que 1 ou 5Mo max par fichier ?
Le tail pourrait alors peut être ne plus tuer la connexion ?

Re: Truc louche avec ssh

[Marc Chantreux]

marc

>   Non, non, ce n'est pas ça. Ce problème peut survenir mais pas dans mon
> cas où il est exclu par construction. Les paquets passent quels que
> soient leur taille.

y'a des dispositifs filtrant entre toi et le serveur? le problème n'est
pas dans les bouts?

marc

Re: Truc louche avec ssh

[BERTRAND Joël]

Charles Plessy a écrit :
> Bonsoir à tous,
> 
> je me souviens d'avoir eu exactement le même problème.
> 
> J'ai même peut-être eu la solution sur cette liste (ou le LUG de
> Strasbourg ?), mais je n'arrive pas à la retrouver.
> 
> Je vais peut-être me tromper, mais il me semble que le problème était
> lié à la MTU ou un système similaire: tant qu'on pianote un peu, les
> paquets échangés sont petits, mais dès qu'on fait défiler des tonnes
> de texte avec une sortie standard ou un copier-collé, un gros paquet
> est créé et fait planter la connection pour une raison dont je ne me
> souviens plus.
> 
> En espérant que ça aide, au moins en tant que soutien moral.

Non, non, ce n'est pas ça. Ce problème peut survenir mais pas dans mon
cas où il est exclu par construction. Les paquets passent quels que
soient leur taille.

Bien cordialement,

JKB

Re: Truc louche avec ssh

[Charles Plessy]

Bonsoir à tous,

je me souviens d'avoir eu exactement le même problème.

J'ai même peut-être eu la solution sur cette liste (ou le LUG de
Strasbourg ?), mais je n'arrive pas à la retrouver.

Je vais peut-être me tromper, mais il me semble que le problème était
lié à la MTU ou un système similaire: tant qu'on pianote un peu, les
paquets échangés sont petits, mais dès qu'on fait défiler des tonnes
de texte avec une sortie standard ou un copier-collé, un gros paquet
est créé et fait planter la connection pour une raison dont je ne me
souviens plus.

En espérant que ça aide, au moins en tant que soutien moral.

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Truc louche avec ssh

[Marc Chantreux]

Bonjour Sébastien,

> Quoi qu'il en soit, cette hypothèse me semble très probable, c'est pour
> cela que j'en ai fait part, mais ce n'est qu'une hypothèse.

c'est bien pour ca que ca m'intéresse: si tmux,screen ou mosh
contournent le problème, ca ne le corrige ni ne l'explique et j'étais
curieux.

merci pour ta réponse.

marc

Re: Truc louche avec ssh

[Sébastien Dinot]

Marc Chantreux a écrit :
> Oui mais du coup ca n'explique pas le comportement curieux que décrit
> Bertrand. je crois comprendre que dans les 2 cas:
> 
> * on a une session interactive ouverte sur la machine distante
> * un processus qui ne fait rien qui est attaché à la tty

Ce n'est pas ce qu'il a dit :

1. « Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
 plusieurs jours et *sans aucune action de ma part*, la connexino
 ssh ne plante pas »

2. « dès que je fais dérouler un tail -F /var/log/apache2/access.log
 (par exemple), la connexion se coupe très rapidement »

> je comprendrais pas pourquoi un vi resisterait mieux à un tail dans le
> cas d'une perte de paquets.

L'un ne résiste pas mieux que l'autre, c'est juste que tail sollicite
bien plus fréquemment la connexion (en transmettant régulièrement des
informations) que Vi. Avec Vi (ou tout autre éditeur en mode texte), si
l'utilisateur n'effectue aucune saisie, seuls les pings applicatifs de
SSH circulent sur le lien (et SSH résiste à des coupures ponctuelles).
De son côté, tail affiche tout nouveau message de log et le serveur SSH
va donc chercher à le transmettre au client, il sollicite la connexion.

Quoi qu'il en soit, cette hypothèse me semble très probable, c'est pour
cela que j'en ai fait part, mais ce n'est qu'une hypothèse.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Truc louche avec ssh

[BERTRAND Joël]

Marc Chantreux a écrit :
> salut Joel,

Bonsoir,

>> Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
>> plusieurs jours et sans aucune action de ma part
> 
> tmux est parfait pour ce genre d'usages: il te permet de lier tes applis
> à un serveur de sessions plutôt qu'à la connexion ssh liée au terminal
> courant. Du coup tu peux te déconnecter, te reconnecter depuis une autre
> machine, te connecter a plusieurs sur la même sessions ...
> 
> ca te permet aussi d'ouvrir plusieurs fenetres ou de splitter les
> fenetres existantes, de mutltiplexer la saisie sur plusieurs terminaux
> (pour tapper la meme commande sur plusieurs serveurs ...) ... bref: en
> plus de résoudre ton problème, ca t'ouvrirais pas mal de possibilités
> comme fermer ta connexion ssh (et éteindre ta machine) sans perdre tes
> terminaux.

Pour cela, étant donné que je suis un vieux machin, j'utilise screen
depuis des années.

JB

Re: Truc louche avec ssh

[Marc Chantreux]

> Cela ne stabilise rien du tout, bien au contraire, un trafic incessant
> révèle l'instabilité de la connexion, là où une connexion entretenue par
> un simple « ping applicatif » ponctuel ne révèle rien du tout.

Oui mais du coup ca n'explique pas le comportement curieux que décrit
Bertrand. je crois comprendre que dans les 2 cas:

* on a une session interactive ouverte sur la machine distante
* un processus qui ne fait rien qui est attaché à la tty

je comprendrais pas pourquoi un vi resisterait mieux à un tail dans le
cas d'une perte de paquets.

a+
marc

Re: Truc louche avec ssh

[Marc Chantreux]

salut Joel,

> Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
> plusieurs jours et sans aucune action de ma part

tmux est parfait pour ce genre d'usages: il te permet de lier tes applis
à un serveur de sessions plutôt qu'à la connexion ssh liée au terminal
courant. Du coup tu peux te déconnecter, te reconnecter depuis une autre
machine, te connecter a plusieurs sur la même sessions ...

ca te permet aussi d'ouvrir plusieurs fenetres ou de splitter les
fenetres existantes, de mutltiplexer la saisie sur plusieurs terminaux
(pour tapper la meme commande sur plusieurs serveurs ...) ... bref: en
plus de résoudre ton problème, ca t'ouvrirais pas mal de possibilités
comme fermer ta connexion ssh (et éteindre ta machine) sans perdre tes
terminaux.

cordialement,
marc

Re: Truc louche avec ssh

[BERTRAND Joël]

BERTRAND Joël a écrit :
> Sébastien Dinot a écrit :
>> Basile Starynkevitch a écrit :
>>> je crois qu'il faut le compiler depuis son code source
>>
>> Inutile, l'outil est disponible en version 1.3.2 (dernière version
>> publiée par le projet, en juillet 2017) dans les versions stable,
>> testing et unstable de Debian :
>>
>> https://tracker.debian.org/pkg/mosh
> 
>   Je viens de l'installer, je vous tiens au courant.

Ça a l'air de résoudre le problème.

Merci,

JKB

Re: Truc louche avec ssh

[Sébastien Dinot]

Marc Chantreux a écrit :
> Je pige pas par quel mécanisme et à quel niveau le fait qu'il y est un
> traffic dans les deux sens stabilise quoi que ce soit. tu pourrais
> expliquer?

Cela ne stabilise rien du tout, bien au contraire, un trafic incessant
révèle l'instabilité de la connexion, là où une connexion entretenue par
un simple « ping applicatif » ponctuel ne révèle rien du tout. Et c'est
d'autant plus vrai avec SSH, qui est conçu pour supporter un certain
nombre de requêtes restent sans réponse (cf. ServerAliveCountMax dans la
page de manuel de ssh_config).

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Truc louche avec ssh

[Marc Chantreux]

> Ne serait-ce tout simplement pas révélateur d'une connexion instable,
> intermittente? Tu ne t'en rends pas compte dans le terminal inactif,
> car la coupure passe justement inaperçue (les sockets restent valides).
> Mais lorsque le flux est continu, là, l'intermittence de la connexion se
> révèle rapidement.

Je pige pas par quel mécanisme et à quel niveau le fait qu'il y est un
traffic dans les deux sens stabilise quoi que ce soit. tu pourrais
expliquer?

cordialement,
marc

Re: Truc louche avec ssh

[BERTRAND Joël]

Sébastien Dinot a écrit :
> Basile Starynkevitch a écrit :
>> je crois qu'il faut le compiler depuis son code source
> 
> Inutile, l'outil est disponible en version 1.3.2 (dernière version
> publiée par le projet, en juillet 2017) dans les versions stable,
> testing et unstable de Debian :
> 
> https://tracker.debian.org/pkg/mosh

Je viens de l'installer, je vous tiens au courant.

JKB

Re: Truc louche avec ssh

[Sébastien Dinot]

Basile Starynkevitch a écrit :
> je crois qu'il faut le compiler depuis son code source

Inutile, l'outil est disponible en version 1.3.2 (dernière version
publiée par le projet, en juillet 2017) dans les versions stable,
testing et unstable de Debian :

https://tracker.debian.org/pkg/mosh

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Truc louche avec ssh

[BERTRAND Joël]

Basile Starynkevitch a écrit :
> 
> On 4/16/21 10:01 PM, Sébastien Dinot wrote:
>> BERTRAND Joël a écrit :
>>> Rien à signaler dans tcpdump. C'est la première chose que j'ai
>>> regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
>>> un routeur quelque part qui coupe, mais je ne vois pas comment il
>>> ferait la différence entre un terminal inactif et un tail -F.
>> Ne serait-ce tout simplement pas révélateur d'une connexion instable,
>> intermittente ? Tu ne t'en rends pas compte dans le terminal inactif,
>> car la coupure passe justement inaperçue (les sockets restent valides).
>> Mais lorsque le flux est continu, là, l'intermittence de la connexion se
>> révèle rapidement.
>>
>> Sébastien
> 
> 
> On pourrait dans ce cas utiliser mosh.
> 
> https://mosh.org/

Tiens, je n'avais pas pensé à ça. Effectivement, avec ma connexion de
type Internet pour les plouc (le réseau téléphonique d'Orange est plus
que foireux dans mon coin et j'attends la fibre avec une certaine
impatiente !), j'ai assez souvent des bagots. Après plus d'un an de
combat avec Orange (je suis en dégroupage partiel Nerim), la SEULE chose
que j'ai obtenu, c'est qu'ils limitent le débit de la ligne de 7,5 Mbps
à moins de 4 ! Pour envoyer des fichiers de fabrication à l'autre bout
du monde, j'en suis à envoyer des cartes SD par UPS !

Merci, je teste,

JKB

Re: Truc louche avec ssh

[Basile Starynkevitch]

On 4/16/21 10:01 PM, Sébastien Dinot wrote:

BERTRAND Joël a écrit :

Rien à signaler dans tcpdump. C'est la première chose que j'ai
regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
un routeur quelque part qui coupe, mais je ne vois pas comment il
ferait la différence entre un terminal inactif et un tail -F.

Ne serait-ce tout simplement pas révélateur d'une connexion instable,
intermittente ? Tu ne t'en rends pas compte dans le terminal inactif,
car la coupure passe justement inaperçue (les sockets restent valides).
Mais lorsque le flux est continu, là, l'intermittence de la connexion se
révèle rapidement.

Sébastien



On pourrait dans ce cas utiliser mosh.

https://mosh.org/

je crois qu'il faut le compiler depuis son code source

--

Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Truc louche avec ssh

[Sébastien Dinot]

BERTRAND Joël a écrit :
> Rien à signaler dans tcpdump. C'est la première chose que j'ai
> regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
> un routeur quelque part qui coupe, mais je ne vois pas comment il
> ferait la différence entre un terminal inactif et un tail -F.

Ne serait-ce tout simplement pas révélateur d'une connexion instable,
intermittente ? Tu ne t'en rends pas compte dans le terminal inactif,
car la coupure passe justement inaperçue (les sockets restent valides).
Mais lorsque le flux est continu, là, l'intermittence de la connexion se
révèle rapidement.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

Re: Truc louche avec ssh

[BERTRAND Joël]

Thomas Trupel a écrit :
> Bonjour,
> 
> Un tcpdump permettrait de savoir qui met fin à la session tcp.

Bonsoir,

Rien à signaler dans tcpdump. C'est la première chose que j'ai
regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
un routeur quelque part qui coupe, mais je ne vois pas comment il ferait
la différence entre un terminal inactif et un tail -F.

JKB

Re: Truc louche avec ssh

[Thomas Trupel]

Bonjour,

Un tcpdump permettrait de savoir qui met fin à la session tcp.

Cordialement,
Thomas

16 avr. 2021 18:33:40 BERTRAND Joël :

>   Bonjour à tous,
> 
>   Chose louche que je ne m'explique pas. J'ai un serveur distant en
> centre d'hébergement. J'ai accès à la console (au travers d'un genre de
> kvm IP) et j'y accède en ssh. Ce n'est pas exactement une Debian mais
> une Devuan. Côté client, on est en devian, l'honneur est sauf !
> 
>   Parfait.
> 
>   Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
> plusieurs jours et sans aucune action de ma part, la connexino ssh ne
> plante pas (j'ai naturellement mis l'option KeepAlive dans la
> configuration de sshd).
> 
>   Mais, dès que je fais dérouler un tail -F /var/log/apache2/access.log
> (par exemple), la connexion se coupe très rapidement.
> 
>   Je ne trouve aucune explication valable... ni naturellement comment
> contourner le problème puisque je n'arrive pas à l'identifier.
> 
>   Merci de vos lumières,
> 
>   JKB

Truc louche avec ssh

[BERTRAND Joël]

Bonjour à tous,

Chose louche que je ne m'explique pas. J'ai un serveur distant en
centre d'hébergement. J'ai accès à la console (au travers d'un genre de
kvm IP) et j'y accède en ssh. Ce n'est pas exactement une Debian mais
une Devuan. Côté client, on est en devian, l'honneur est sauf !

Parfait.

Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
plusieurs jours et sans aucune action de ma part, la connexino ssh ne
plante pas (j'ai naturellement mis l'option KeepAlive dans la
configuration de sshd).

Mais, dès que je fais dérouler un tail -F /var/log/apache2/access.log
(par exemple), la connexion se coupe très rapidement.

Je ne trouve aucune explication valable... ni naturellement comment
contourner le problème puisque je n'arrive pas à l'identifier.

Merci de vos lumières,

JKB

Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.

[Étienne Mollier]

Bonjour Charles,

Charles Plessy, on 2020-11-14 18:23:21 +0900:
> Le Thu, Nov 12, 2020 at 09:51:06PM +0100, Étienne Mollier a écrit :
> > $ export GIT_SSH_COMMAND='ssh -vvv'
> > $ git clone g...@salsa.debian.org:med-team/perlprimer.git
> 
> Merci du tuyau, ça bloque à:
> 
> debug1: Sending command: git-upload-pack 'med-team/perlprimer.git'
> debug2: channel 1: request exec confirm 1
> debug3: send packet: type 98
> debug2: channel_input_open_confirmation: channel 1: callback done
> debug2: channel 1: open confirm rwindow 0 rmax 32768
> 
> Google ou DuckDuckGo ne révèlent rien concernant "git-upload-pack"
> "ipv6" "freeze"

Je sèche.  C'est vrai que c'est curieux.  On est loin dans
l'exécution de la commande `git clone` : la connexion SSH est
déjà établie, et les clés sont échangées depuis bien longtemps.
Chez moi, la connexion se poursuit comme suit:

debug1: Sending command: git-upload-pack 'med-team/perlprimer.git'
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
remote: Enumerating objects: 660, done.
remote: Counting objects: 100% (660/660), done.
remote: Compressing objects: 100% (299/299), done.

Soit la commande "git-upload-pack 'med-team/perlprimer.git'"
ne démarre pas du côté de Salsa, soit elle n'arrive pas à
utiliser la liaison existante avec votre machine pour renvoyer
la confirmation (paquet type 99).

> (Je n'ai pas encore testé le changement de MTU; je ne sais pas comment
> le faire sure une interface wifi gérée par GNOME...)

La suggestion de Daniel "NoSpam" avec "ip" me semble à explorer.
J'ai des souvenirs d'école comme quoi IPv6 ne fragmente pas
comme IPv4, et du coup un MTU trop gros peut potentiellement
bloquer si la route se dégrade en cours de connexion (je ne suis
pas spécialiste en réseau, et le souvenir en question date d'il
y a dix ans, donc je peux dire des bêtises).

> (Je n'ai pas testé non plus la version 2.29; je suis en 2.27)

J'ai testé rapidement avec Git 2.20 de Buster, mais je n'ai pas
observé plus de blocages, sinon effectivement, mon test était
avec Git 2.29.

> Bon week-end !

Merci, à vous de même,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.

[NoSpam]

Bonjour

Le 14/11/2020 à 10:23, Charles Plessy a écrit :

[...]
(Je n'ai pas encore testé le changement de MTU; je ne sais pas comment
le faire sure une interface wifi gérée par GNOME...)


en ligne de commande: sudo ip link set mtu 1492 dev 

--
Daniel

Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.

[Charles Plessy]

Le Thu, Nov 12, 2020 at 09:51:06PM +0100, Étienne Mollier a écrit :
> 
> Je n'ai pas rencontré de problèmes de mon côté.  En grattant un
> peu, la variable d'environnement GIT_SSH_COMMAND peut être
> exploitée pour augmenter le verbiage de ssh:
> 
>   $ export GIT_SSH_COMMAND='ssh -vvv'
>   $ git clone g...@salsa.debian.org:med-team/perlprimer.git

Merci du tuyau, ça bloque à:

debug1: Sending command: git-upload-pack 'med-team/perlprimer.git'
debug2: channel 1: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 1: callback done
debug2: channel 1: open confirm rwindow 0 rmax 32768

Google ou DuckDuckGo ne révèlent rien concernant "git-upload-pack"
"ipv6" "freeze"

(Je n'ai pas encore testé le changement de MTU; je ne sais pas comment
le faire sure une interface wifi gérée par GNOME...)

(Je n'ai pas testé non plus la version 2.29; je suis en 2.27)

Bon week-end !

-- 
Charles

Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.

[Fabien R]

On 12/11/2020 21:51, Étienne Mollier wrote:


De mon point de vue, Github n'est pas accessible en IPv6, ou du
moins, n'en fait pas la publicité :

$ host github.com
github.com has address 140.82.113.3
github.com mail is handled by 10 alt3.aspmx.l.google.com.
github.com mail is handled by 10 alt4.aspmx.l.google.com.
github.com mail is handled by 1 aspmx.l.google.com.
github.com mail is handled by 5 alt1.aspmx.l.google.com.
github.com mail is handled by 5 alt2.aspmx.l.google.com.

Ceci pourrait expliquer cela...

J'ai également constaté que dig ne renvoyait aucune donnée .
--
Fabien

Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.

[NoSpam]

Bonjour

Le 12/11/2020 à 21:22, Charles Plessy a écrit :

Bonjour à tous,

j'ai à nouveau la fibre.  Et en IPv6 en plus.  Mais Git n'arrive plus à
contacter des sites distants en SSH.

Curieusement, les sessions SSH interactives ont l'air de s'établir
normalement.  Example:

 $ ssh -6 g...@salsa.debian.org
 PTY allocation request failed on channel 1
 Welcome to GitLab, @plessy!
 Connection to salsa.debian.org closed.

(C'est la réponse attendue).

Par contre:

 $ git clone --verbose g...@salsa.debian.org:med-team/perlprimer.git
 Clonage dans 'perlprimer'...

… et ensuite plus rien.

Si je désactive IPv6 pour les connections SSH dans ~/.ssh/config:

 Host *
AddressFamily inet

Tout rentre dans l'ordre.  Mais ce n'est pas satisfaisant :)

Le problème n'est pas spécifique au réseau Debian; j'ai la même chose
avec branchable.com et gitlab.com.  Par contre, ça fonctionne avec
GitHub...

Quelqu'un aurait-il une piste ?


Essaye avec une MTU a 1492

--
Daniel

Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.

[Étienne Mollier]

Bonjour Charles,

Charles Plessy, on 2020-11-13 05:22:08 +0900:
> j'ai à nouveau la fibre.  Et en IPv6 en plus.  Mais Git n'arrive plus à
> contacter des sites distants en SSH.
> 
> Curieusement, les sessions SSH interactives ont l'air de s'établir
> normalement.  Example:
> 
> $ ssh -6 g...@salsa.debian.org
> PTY allocation request failed on channel 1
> Welcome to GitLab, @plessy!
> Connection to salsa.debian.org closed.
> 
> (C'est la réponse attendue).
> 
> Par contre:
> 
> $ git clone --verbose g...@salsa.debian.org:med-team/perlprimer.git
> Clonage dans 'perlprimer'...
> 
> … et ensuite plus rien.

Je n'ai pas rencontré de problèmes de mon côté.  En grattant un
peu, la variable d'environnement GIT_SSH_COMMAND peut être
exploitée pour augmenter le verbiage de ssh:

$ export GIT_SSH_COMMAND='ssh -vvv'
$ git clone g...@salsa.debian.org:med-team/perlprimer.git

Peut-être qu'il en sortira quelque chose d'intéressant ?

> Si je désactive IPv6 pour les connections SSH dans ~/.ssh/config:
> 
> Host *
>AddressFamily inet
> 
> Tout rentre dans l'ordre.  Mais ce n'est pas satisfaisant :)
> 
> Le problème n'est pas spécifique au réseau Debian; j'ai la même chose
> avec branchable.com et gitlab.com.  Par contre, ça fonctionne avec
> GitHub...

De mon point de vue, Github n'est pas accessible en IPv6, ou du
moins, n'en fait pas la publicité :

$ host github.com
github.com has address 140.82.113.3
github.com mail is handled by 10 alt3.aspmx.l.google.com.
github.com mail is handled by 10 alt4.aspmx.l.google.com.
github.com mail is handled by 1 aspmx.l.google.com.
github.com mail is handled by 5 alt1.aspmx.l.google.com.
github.com mail is handled by 5 alt2.aspmx.l.google.com.

Ceci pourrait expliquer cela...

Bonne journée,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/7, please excuse my verbosity.


signature.asc
Description: PGP signature

Git n'arrive pas à contacter certains sites IPv6 en SSH.

[Charles Plessy]

Bonjour à tous,

j'ai à nouveau la fibre.  Et en IPv6 en plus.  Mais Git n'arrive plus à
contacter des sites distants en SSH.

Curieusement, les sessions SSH interactives ont l'air de s'établir
normalement.  Example:

$ ssh -6 g...@salsa.debian.org
PTY allocation request failed on channel 1
Welcome to GitLab, @plessy!
Connection to salsa.debian.org closed.

(C'est la réponse attendue).

Par contre:

$ git clone --verbose g...@salsa.debian.org:med-team/perlprimer.git
Clonage dans 'perlprimer'...

… et ensuite plus rien.

Si je désactive IPv6 pour les connections SSH dans ~/.ssh/config:

Host *
   AddressFamily inet

Tout rentre dans l'ordre.  Mais ce n'est pas satisfaisant :)

Le problème n'est pas spécifique au réseau Debian; j'ai la même chose
avec branchable.com et gitlab.com.  Par contre, ça fonctionne avec
GitHub...

Quelqu'un aurait-il une piste ?

Charles

-- 
Charles Plessy
Nagahama, Yomitan, Okinawa, Japon

Re: install par copie et ssh

[Marc Chantreux]

> Bizarement l'option est dans la page de manuel d'apt-get mais pas celle
> d'apt...

dans man apt(8)

   Exactement comme apt lui-même, cette page de manuel vise à être une 
interface pour
   l'utilisateur et ainsi elle ne mentionne que les commandes et les 
options les plus
   courantes, en partie pour ne pas répéter les informations à de multiples 
emplacements et
   en partie pour ne pas noyer le lecteur par une surabondance d'options et 
de détails.

...

   install, reinstall, remove, purge (apt-get(8))

il est fait mention de apt-get(8). c'est probablement une façon de dire
que si tu veut les détails, c'est là que ça se passe.

cordialement,
marc

Re : install par copie et ssh

[nicolas . patrois]

Le 19/09/2020 14:10:35, Eric Laly a écrit :

> Bonjour,

> ou un paramètre sur la ligne de commande apt...
> par exemple:
> 'apt install mercurial tortoisehg tortoisehg-nautilus -y'

> Bizarement l'option est dans la page de manuel d'apt-get mais pas
> celle d'apt...

Peut-être parce qu’apt n’est pas encore stabilisé.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: install par copie et ssh

[Eric Laly]

Bonjour,

ou un paramètre sur la ligne de commande apt...
par exemple:
'apt install mercurial tortoisehg tortoisehg-nautilus -y'

Bizarement l'option est dans la page de manuel d'apt-get mais pas celle 
d'apt...


Éric.

Le 18/09/2020 à 16:46, Dominique Dumont a écrit :

On Thursday, 17 September 2020 15:53:49 CEST Pierre Malard wrote:

Je n’ai pas encore trouver le moyen de forcer le YES.

Tu peux essayer la commande "yes".

par exemple: yes | apt install stuff

HTH

Re: install par copie et ssh

[Dominique Dumont]

On Thursday, 17 September 2020 15:53:49 CEST Pierre Malard wrote:
> Je n’ai pas encore trouver le moyen de forcer le YES.

Tu peux essayer la commande "yes".

par exemple: yes | apt install stuff

HTH

Re: install par copie et ssh

[Pierre Malard]

Super,

J’avais lu le man trop vite !

Merci

> Le 17 sept. 2020 à 12:52, Frédéric MASSOT  a 
> écrit :
> 
> Le 17/09/2020 à 12:26, hamster a écrit :
>> Salut.
>> 
>> Comme d'autres, j'aime bien installer debian en copiant un système
>> existant plutot qu'en refesant tout le processus d'install. C'est plus
>> rapide et utilise
>> moins le reseau.
>> 
>> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
>> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
>> copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef
>> d'identification. Je cherche donc a renouveller ces clef après copie,
>> mais tant dans google que dans les man, je me perds.
>> 
>> Si quelqu'un a une piste a me donner, je suis preneur.
> 
> Tu supprimes ou tu renommes (par précaution) les anciennes clés, puis tu
> créés de nouvelles avec :
> 
> sudo ssh-keygen -A
> 
> 
> 
> --
> ==
> |  FRÉDÉRIC MASSOT   |
> | http://www.juliana-multimedia.com  |
> |   mailto:frede...@juliana-multimedia.com   |
> | +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
> ===Debian=GNU/Linux===
> 

--
Pierre Malard


  «Quand un Français dit du mal de lui, ne le croyez pas, Il se vante !»
   Édouard Pailleron
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--


signature.asc
Description: Message signed with OpenPGP

Re: install par copie et ssh

[Pierre Malard]

Bonjour,

Il te suffit de régénérer ces clés du serveur avec un « ssh-keygen » une
fois la copie effectuée sur chaque type de clé. Par exemple en exécutant
ceci :
# for i in $(ls -1d /etc/ssh/ssh_host_*_key) ; do ssh-keygen -t "$(echo 
${i/\/etc\/ssh\/ssh_host_} | cut -d_ -f1)" -N '' -f "${i}" -C 
"root@$(hostname)"; done

Tu répond « y » à chaque fois qu’il te demande si tu veux l’écraser.
Je n’ai pas encore trouver le moyen de forcer le YES.

A+


> Le 17 sept. 2020 à 12:26, hamster  a écrit :
> 
> Salut.
> 
> Comme d'autres, j'aime bien installer debian en copiant un système
> existant plutot qu'en refesant tout le processus d'install. C'est plus
> rapide et utilise
> moins le reseau.
> 
> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
> copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef
> d'identification. Je cherche donc a renouveller ces clef après copie,
> mais tant dans google que dans les man, je me perds.
> 
> Si quelqu'un a une piste a me donner, je suis preneur.
> 

--
Pierre Malard


« L'utopie, c'est la vérité de demain »
 Victor Hugo (1802-1885)
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: install par copie et ssh

[hamster]

Le 17/09/2020 à 12:52, Frédéric MASSOT a écrit :
> Le 17/09/2020 à 12:26, hamster a écrit :
>> Salut.
>>
>> Comme d'autres, j'aime bien installer debian en copiant un système
>> existant plutot qu'en refesant tout le processus d'install. C'est plus
>> rapide et utilise
>> moins le reseau.
>>
>> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
>> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
>> copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef
>> d'identification. Je cherche donc a renouveller ces clef après copie,
>> mais tant dans google que dans les man, je me perds.
>>
>> Si quelqu'un a une piste a me donner, je suis preneur.
> Tu supprimes ou tu renommes (par précaution) les anciennes clés, puis tu
> créés de nouvelles avec :
>
> sudo ssh-keygen -A

Super, ca marche nickel, merci.

Re: install par copie et ssh

[Frédéric MASSOT]

Le 17/09/2020 à 12:26, hamster a écrit :
> Salut.
> 
> Comme d'autres, j'aime bien installer debian en copiant un système
> existant plutot qu'en refesant tout le processus d'install. C'est plus
> rapide et utilise
> moins le reseau.
> 
> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
> copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef
> d'identification. Je cherche donc a renouveller ces clef après copie,
> mais tant dans google que dans les man, je me perds.
> 
> Si quelqu'un a une piste a me donner, je suis preneur.

Tu supprimes ou tu renommes (par précaution) les anciennes clés, puis tu
créés de nouvelles avec :

sudo ssh-keygen -A



-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: install par copie et ssh

[Marc Chantreux]

salut,

Je cherche donc a renouveller ces clef après copie,
> mais tant dans google que dans les man, je me perds.

je n'ai regardé ni le man, ni google pour te répondre mais

apt source openssh-server
vim openssh-8.3p1/debian/openssh-server.postinst

regarde la fonction create_keys et tu devrais pouvoir adapter à ton
problème.

cordialement,
marc

Re: install par copie et ssh

[Belaïd]

Bonjour,

Tu peux la recréée facilement avec une ligne de commande: ssh-keygen -t rsa.



Le jeu. 17 sept. 2020 12:41, hamster  a écrit :

> Le 17/09/2020 à 12:31, Bernard Schoenacker a écrit :
> >
> > - Mail original -
> >> De: "hamster" 
> >> À: debian-user-french@lists.debian.org
> >> Envoyé: Jeudi 17 Septembre 2020 12:26:23
> >> Objet: install par copie et ssh
> >>
> >> Salut.
> >>
> >> Comme d'autres, j'aime bien installer debian en copiant un système
> >> existant plutot qu'en refesant tout le processus d'install. C'est
> >> plus
> >> rapide et utilise
> >> moins le reseau.
> >>
> >> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
> >> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
> >> copie, on se retrouve donc avec plusieurs ordis qui ont les memes
> >> clef
> >> d'identification. Je cherche donc a renouveller ces clef après copie,
> >> mais tant dans google que dans les man, je me perds.
> >>
> >> Si quelqu'un a une piste a me donner, je suis preneur.
> >>
> >
> > bonjour,
> >
> > je conseille de passer par debootstrap et ensuite
> > de remonter le système 
>
> Merci bien mais je ne comprend rien a ce que tu me dit.
>
>

Re: install par copie et ssh

[hamster]

Le 17/09/2020 à 12:31, Bernard Schoenacker a écrit :
>
> - Mail original -
>> De: "hamster" 
>> À: debian-user-french@lists.debian.org
>> Envoyé: Jeudi 17 Septembre 2020 12:26:23
>> Objet: install par copie et ssh
>>
>> Salut.
>>
>> Comme d'autres, j'aime bien installer debian en copiant un système
>> existant plutot qu'en refesant tout le processus d'install. C'est
>> plus
>> rapide et utilise
>> moins le reseau.
>>
>> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
>> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
>> copie, on se retrouve donc avec plusieurs ordis qui ont les memes
>> clef
>> d'identification. Je cherche donc a renouveller ces clef après copie,
>> mais tant dans google que dans les man, je me perds.
>>
>> Si quelqu'un a une piste a me donner, je suis preneur.
>>
>
> bonjour,
>
> je conseille de passer par debootstrap et ensuite
> de remonter le système 

Merci bien mais je ne comprend rien a ce que tu me dit.

Re: install par copie et ssh

[Bernard Schoenacker]

- Mail original -
> De: "hamster" 
> À: debian-user-french@lists.debian.org
> Envoyé: Jeudi 17 Septembre 2020 12:26:23
> Objet: install par copie et ssh
> 
> Salut.
> 
> Comme d'autres, j'aime bien installer debian en copiant un système
> existant plutot qu'en refesant tout le processus d'install. C'est
> plus
> rapide et utilise
> moins le reseau.
> 
> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
> copie, on se retrouve donc avec plusieurs ordis qui ont les memes
> clef
> d'identification. Je cherche donc a renouveller ces clef après copie,
> mais tant dans google que dans les man, je me perds.
> 
> Si quelqu'un a une piste a me donner, je suis preneur.
> 


bonjour,

je conseille de passer par debootstrap et ensuite
de remonter le système 

attention aux cartes réseau et à leurs "adresses" 

merci

@+
bernard

install par copie et ssh

[hamster]

Salut.

Comme d'autres, j'aime bien installer debian en copiant un système
existant plutot qu'en refesant tout le processus d'install. C'est plus
rapide et utilise
moins le reseau.

Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
identifier l'ordi quand on s'y connecte en ssh. Si on installe par
copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef
d'identification. Je cherche donc a renouveller ces clef après copie,
mais tant dans google que dans les man, je me perds.

Si quelqu'un a une piste a me donner, je suis preneur.

Re: Lancer une appli graphique en ssh : ça s'améliore

[Sébastien NOBILI]

Bonjour,

Le 2020-04-22 20:11, ajh-valmer a écrit :

Du client :
ssh -v -p  root@ -X xeyes

debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending command: xeyes
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 
16384

debug1: client_request_x11: request from 127.0.0.1 55856
connect localhost port 6001: Connection refused


Est-ce qu'il n'y aurait pas des règles de firewall (sur le serveur SSH) 
qui bloqueraient l'accès à ce port ?


sudo iptables -L -n -v

Est-ce que le serveur SSH a mis en place l'écoute sur ce port ?

ssh -X -p  root@
sudo netstat -peanut | grep sshd

Pourquoi est-ce que ce numéro de port vaut 6001 alors que dans la 
configuration par défaut de SSHd, il devrait être 6010 ?


ssh -X -p  root@
grep X11DisplayOffset /etc/ssh/sshd_config

Est-ce que xauth est installé sur le serveur SSH (la machine 
"") ?


dpkg -l | grep xauth

Qu'est-ce que ça donne en décomposant les étapes ?

ssh -X -p  root@
echo $DISPLAY
xeyes

Qu'est-ce que ça donne en se connectant avec un autre compte utilisateur 
?


ssh -X -p  user@
echo $DISPLAY
xeyes

Sébastien

Re: Lancer une appli graphique en ssh : ça s'améliore pas

[Antoine Olczak]

Le 22/04/2020 à 23:43:08 (+0200), ajh-valmer a écrit :
> On Wednesday 22 April 2020 21:49:25 NoSpam wrote:
> > Je trouve que votre agressivité est déplacée, des personnes tentent de 
> > vous aider et vous focalisez sur vous même. Vous êtes coutumier du fait, 
> > hélas, et les personnes de la liste n'ont pas à subir cela.
> 
> Je ne vois pas en quoi mon mail ci-dessous est "agressif",
> et "je me focalise sur moi même".
> Je le ponctue d'un smiley souriant et d'un "bonne soirée".
> "En quoi les personnes de la liste ont à subir cela",
> c'est un help normal.
> 
> Malgré mes demandes répétées, pourquoi je reçois tjrs des 
> mails en 3 exemplaires.  Est-ce cela, "être coutumier du fait" ?
> 
> Je n'avais pas trop insisté sur cette panne,
> j'avais abandonné et c'est S. Bortzmeyer qui l'a relancée bien plus tard,
> avec un côté reprochant désagréable.
> (une personne de la ML l'a aussi constaté...).
> 
> Franchement, je ne comprends pas ta réaction,
> alors arrêtons et fermons tous les ML, forums, endroits de dialogues etc...
> 

Je suis à des années-lumière du niveau de compétences techniques de 
S. Bortzmeyer mais je sais moi-même qu’on utilise pas « xhost + » sur
une machine accessible via le réseau et qu’il s’agit dans presque tous
les cas d’une solution de facilité à un problème mal posé.

Je n’ai pas non plus l’habitude de suivre aveuglément les
recommandations, mais si S.Bortzmeyer me reprenait sur ce genre de
questions, je commencerais par m’en contenter (c’est-à-dire agir
immédiatement) avant de chercher à faire autrement et me documenter.

Il n’est en rien tenu d’apporter une solution à un problème pour être
légitime à alerter concernant un danger. Sans le connaitre
personnellement, je n’ai pas de mal à imaginer que son intervention
relève d’une nécessité éthique face au constat d’une « mauvaise pratique
», voire d’une pratique dangereuse.

Ce n’est pas juste d’attaquer S. Bortzmeyer parce qu’il a agit comme il
le devait. C’est une chance d’avoir l’opportunité d’interagir avec une
personne de cette qualité et il est dommage de ne pas faire preuve d’un
minimun de respect face à une personne dont on ne peut douter ni de
l’engagement ni des compétences quelque soit les questions de
compatibilité caractérielle.

Je pense qu’il n’a rien à prouver en terme de contribution à la
circulation de la connaissance sur les questions relatives à
l’ingénierie des réseaux, aux techniciens et bien au-delà. D’ailleurs ces
réponses me semblent être claires et apporter des pistes exploitables
pour qui veut bien les suivre. Ce n’est peut-être pas la réponse
clé-en-mains attendue.

Quant à lui donner des leçons sur les standards d’utilisation des
protocoles, j’espère que c’est au mieux une blague, au pire une
provocation gratuite !

J’espère que cela ne le refroidira pas de participer à cette liste.
Je l’ai moi-même déjà été et pense me désabonner prochainement, car
suivre une liste de discussion est fatiguant quand il faut passer les
polémiques stériles, inutile quand il faut appliquer des règles sieve
sur son serveur pour ne pas subir le bruit.

Re: Lancer une appli graphique en ssh : ça s'améliore

[Frederic Zulian]

Hmm, peux être une piste.
Je vois que tu te connectes au serveur via SSH en Root.

Par défaut les connections en Root sont refusées par SSH.

Frédéric ZULIAN

Le mer. 22 avr. 2020 à 20:12, ajh-valmer  a écrit :

> Comment dialoguer et me reprocher,
> si vous persistez à envoyer toujours vos mails en TROIS exemplaires,
> encore comme celui ci, malgré cette demande
> dans le précédent.
>
> Du client :
> ssh -v -p  root@ -X xeyes
>
> debug1: Requesting X11 forwarding with authentication spoofing.
> debug1: Sending command: xeyes
> debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
> debug1: client_request_x11: request from 127.0.0.1 55856
> connect localhost port 6001: Connection refused
> debug1: failure x11
> Error: Can't open display: localhost:10.0
>
> Que dire de plus ? :-)
>
> Bonne soirée.
>
> On Wednesday 22 April 2020 15:40:00 Stephane Bortzmeyer wrote:
> > On Wed, Apr 22, 2020 at 11:24:24AM +0200,
> >  ajh-valmer  wrote
> >  a message of 67 lines which said:
> > > > Non. À moins qu'il n'y ait un script quelque part qui redéfinisse
> > > > DISPLAY (ce qu'il ne faut pas faire, ssh le faisant très bien tout
> > > > seul) :
> > > L'erreur affichée a toujours été : "cannot open display:
> > > localhost:10.0".
> > Mais cela n'a rien à voir avec ma question. Je la reformule. Y a-t-il,
> > sur la machine distante, un fichier de configuration, genre .profile
> > ou .zshrc, qui définit explicitement la variable d'environnement
> > DISPLAY ? Cela pourrait expliquer le problème.
> > > > Difficile à dire, comme vous n'avez pas fait de 'ssh -v' (qui
> > > > permettrait de voir le problème) :
> > > Mais si, toutes mes requêtes SSH contenaient évidemment le "-v",
> > J'ai relu la totalité du fil de discussion, et je ne vois pas une
> > seule fois la sortie de la commande 'ssh -v'. Essayer de trouver la
> > cause du problème dans ces conditions, c'est comme déboguer un
> > logiciel dont on n'a pas les sources. C'est possible, mais c'est plus
> > dur.
> > > et X11Forwarding (serveur) était à "yes" dès le départ.
> > Je suis sceptique, puisqu'on n'a pas la sortie de 'ssh -v', et que
> > vous ne dites pas comment vous avez vérifié ce point (dans
> > sshd_config ? Dans ~/.ssh/config ?)
> > > Ce point d'un serveur X à lancer, sur le serveur SSH et/ou le
> > > client,
> > Je maintiens qu'une bonne partie du problème vient de ce que vous
> > n'utilisez pas la bonne terminologie. Notamment, "client" ou "serveur"
> > tout court, sans indication du protocole derrière ("serveur X",
> > "client HTTP") n'a pas de sens (on n'est pas "client" ou "serveur"
> > dans l'absolu, on l'est pour un certain protocole, et même pour une
> > session particulière), et ne fait qu'aggraver la confusion.
> > > Le sujet reste non résolu pour moi.
> > Parce qu'on manque de données.
>
>

Re: Lancer une appli graphique en ssh : ça s'améliore pas

[ajh-valmer]

On Wednesday 22 April 2020 21:49:25 NoSpam wrote:
> Je trouve que votre agressivité est déplacée, des personnes tentent de 
> vous aider et vous focalisez sur vous même. Vous êtes coutumier du fait, 
> hélas, et les personnes de la liste n'ont pas à subir cela.

Je ne vois pas en quoi mon mail ci-dessous est "agressif",
et "je me focalise sur moi même".
Je le ponctue d'un smiley souriant et d'un "bonne soirée".
"En quoi les personnes de la liste ont à subir cela",
c'est un help normal.

Malgré mes demandes répétées, pourquoi je reçois tjrs des 
mails en 3 exemplaires.  Est-ce cela, "être coutumier du fait" ?

Je n'avais pas trop insisté sur cette panne,
j'avais abandonné et c'est S. Bortzmeyer qui l'a relancée bien plus tard,
avec un côté reprochant désagréable.
(une personne de la ML l'a aussi constaté...).

Franchement, je ne comprends pas ta réaction,
alors arrêtons et fermons tous les ML, forums, endroits de dialogues etc...


> Le 22/04/2020 à 20:11, ajh-valmer a écrit :
> > Comment dialoguer et me reprocher,
> > si vous persistez à envoyer toujours vos mails en TROIS exemplaires,
> > encore comme celui ci, malgré cette demande
> > dans le précédent.
> >
> > Du client :
> > ssh -v -p  root@ -X xeyes
> >
> > debug1: Requesting X11 forwarding with authentication spoofing.
> > debug1: Sending command: xeyes
> > debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
> > debug1: client_request_x11: request from 127.0.0.1 55856
> > connect localhost port 6001: Connection refused
> > debug1: failure x11
> > Error: Can't open display: localhost:10.0
> >
> > Que dire de plus ? :-)
> >
> > Bonne soirée.
> >
> > On Wednesday 22 April 2020 15:40:00 Stephane Bortzmeyer wrote:
> >> On Wed, Apr 22, 2020 at 11:24:24AM +0200,
> >>   ajh-valmer  wrote
> >>   a message of 67 lines which said:
> >>>> Non. À moins qu'il n'y ait un script quelque part qui redéfinisse
> >>>> DISPLAY (ce qu'il ne faut pas faire, ssh le faisant très bien tout
> >>>> seul) :
> >>> L'erreur affichée a toujours été : "cannot open display:
> >>> localhost:10.0".
> >> Mais cela n'a rien à voir avec ma question. Je la reformule. Y a-t-il,
> >> sur la machine distante, un fichier de configuration, genre .profile
> >> ou .zshrc, qui définit explicitement la variable d'environnement
> >> DISPLAY ? Cela pourrait expliquer le problème.
> >>>> Difficile à dire, comme vous n'avez pas fait de 'ssh -v' (qui
> >>>> permettrait de voir le problème) :
> >>> Mais si, toutes mes requêtes SSH contenaient évidemment le "-v",
> >> J'ai relu la totalité du fil de discussion, et je ne vois pas une
> >> seule fois la sortie de la commande 'ssh -v'. Essayer de trouver la
> >> cause du problème dans ces conditions, c'est comme déboguer un
> >> logiciel dont on n'a pas les sources. C'est possible, mais c'est plus
> >> dur.
> >>> et X11Forwarding (serveur) était à "yes" dès le départ.
> >> Je suis sceptique, puisqu'on n'a pas la sortie de 'ssh -v', et que
> >> vous ne dites pas comment vous avez vérifié ce point (dans
> >> sshd_config ? Dans ~/.ssh/config ?)
> >>> Ce point d'un serveur X à lancer, sur le serveur SSH et/ou le
> >>> client,
> >> Je maintiens qu'une bonne partie du problème vient de ce que vous
> >> n'utilisez pas la bonne terminologie. Notamment, "client" ou "serveur"
> >> tout court, sans indication du protocole derrière ("serveur X",
> >> "client HTTP") n'a pas de sens (on n'est pas "client" ou "serveur"
> >> dans l'absolu, on l'est pour un certain protocole, et même pour une
> >> session particulière), et ne fait qu'aggraver la confusion.
> >>> Le sujet reste non résolu pour moi.
> >> Parce qu'on manque de données.

[HS] Re: Lancer une appli graphique en ssh : ça s'améliore

[NoSpam]

Je trouve que votre agressivité est déplacée, des personnes tentent de 
vous aider et vous focalisez sur vous même. Vous êtes coutumier du fait, 
hélas, et les personnes de la liste n'ont pas à subir cela.


Le 22/04/2020 à 20:11, ajh-valmer a écrit :

Comment dialoguer et me reprocher,
si vous persistez à envoyer toujours vos mails en TROIS exemplaires,
encore comme celui ci, malgré cette demande
dans le précédent.

Du client :
ssh -v -p  root@ -X xeyes

debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending command: xeyes
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 55856
connect localhost port 6001: Connection refused
debug1: failure x11
Error: Can't open display: localhost:10.0

Que dire de plus ? :-)

Bonne soirée.

On Wednesday 22 April 2020 15:40:00 Stephane Bortzmeyer wrote:

On Wed, Apr 22, 2020 at 11:24:24AM +0200,
  ajh-valmer  wrote
  a message of 67 lines which said:

Non. À moins qu'il n'y ait un script quelque part qui redéfinisse
DISPLAY (ce qu'il ne faut pas faire, ssh le faisant très bien tout
seul) :

L'erreur affichée a toujours été : "cannot open display:
localhost:10.0".

Mais cela n'a rien à voir avec ma question. Je la reformule. Y a-t-il,
sur la machine distante, un fichier de configuration, genre .profile
ou .zshrc, qui définit explicitement la variable d'environnement
DISPLAY ? Cela pourrait expliquer le problème.

Difficile à dire, comme vous n'avez pas fait de 'ssh -v' (qui
permettrait de voir le problème) :

Mais si, toutes mes requêtes SSH contenaient évidemment le "-v",

J'ai relu la totalité du fil de discussion, et je ne vois pas une
seule fois la sortie de la commande 'ssh -v'. Essayer de trouver la
cause du problème dans ces conditions, c'est comme déboguer un
logiciel dont on n'a pas les sources. C'est possible, mais c'est plus
dur.

et X11Forwarding (serveur) était à "yes" dès le départ.

Je suis sceptique, puisqu'on n'a pas la sortie de 'ssh -v', et que
vous ne dites pas comment vous avez vérifié ce point (dans
sshd_config ? Dans ~/.ssh/config ?)

Ce point d'un serveur X à lancer, sur le serveur SSH et/ou le
client,

Je maintiens qu'une bonne partie du problème vient de ce que vous
n'utilisez pas la bonne terminologie. Notamment, "client" ou "serveur"
tout court, sans indication du protocole derrière ("serveur X",
"client HTTP") n'a pas de sens (on n'est pas "client" ou "serveur"
dans l'absolu, on l'est pour un certain protocole, et même pour une
session particulière), et ne fait qu'aggraver la confusion.

Le sujet reste non résolu pour moi.

Parce qu'on manque de données.

Re: Lancer une appli graphique en ssh : ça s'améliore

[ajh-valmer]

Comment dialoguer et me reprocher,
si vous persistez à envoyer toujours vos mails en TROIS exemplaires,
encore comme celui ci, malgré cette demande
dans le précédent.

Du client :
ssh -v -p  root@ -X xeyes 

debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending command: xeyes
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 55856
connect localhost port 6001: Connection refused
debug1: failure x11
Error: Can't open display: localhost:10.0

Que dire de plus ? :-)

Bonne soirée.

On Wednesday 22 April 2020 15:40:00 Stephane Bortzmeyer wrote:
> On Wed, Apr 22, 2020 at 11:24:24AM +0200,
>  ajh-valmer  wrote 
>  a message of 67 lines which said:
> > > Non. À moins qu'il n'y ait un script quelque part qui redéfinisse
> > > DISPLAY (ce qu'il ne faut pas faire, ssh le faisant très bien tout
> > > seul) : 
> > L'erreur affichée a toujours été : "cannot open display:
> > localhost:10.0".
> Mais cela n'a rien à voir avec ma question. Je la reformule. Y a-t-il,
> sur la machine distante, un fichier de configuration, genre .profile
> ou .zshrc, qui définit explicitement la variable d'environnement
> DISPLAY ? Cela pourrait expliquer le problème.
> > > Difficile à dire, comme vous n'avez pas fait de 'ssh -v' (qui
> > > permettrait de voir le problème) :
> > Mais si, toutes mes requêtes SSH contenaient évidemment le "-v",
> J'ai relu la totalité du fil de discussion, et je ne vois pas une
> seule fois la sortie de la commande 'ssh -v'. Essayer de trouver la
> cause du problème dans ces conditions, c'est comme déboguer un
> logiciel dont on n'a pas les sources. C'est possible, mais c'est plus
> dur.
> > et X11Forwarding (serveur) était à "yes" dès le départ.
> Je suis sceptique, puisqu'on n'a pas la sortie de 'ssh -v', et que
> vous ne dites pas comment vous avez vérifié ce point (dans
> sshd_config ? Dans ~/.ssh/config ?)
> > Ce point d'un serveur X à lancer, sur le serveur SSH et/ou le
> > client,
> Je maintiens qu'une bonne partie du problème vient de ce que vous
> n'utilisez pas la bonne terminologie. Notamment, "client" ou "serveur"
> tout court, sans indication du protocole derrière ("serveur X",
> "client HTTP") n'a pas de sens (on n'est pas "client" ou "serveur"
> dans l'absolu, on l'est pour un certain protocole, et même pour une
> session particulière), et ne fait qu'aggraver la confusion.
> > Le sujet reste non résolu pour moi.
> Parce qu'on manque de données.

Re: Lancer une appli graphique en ssh : ça s'améliore

[Stephane Bortzmeyer]

On Wed, Apr 22, 2020 at 11:24:24AM +0200,
 ajh-valmer  wrote 
 a message of 67 lines which said:

> > Non. À moins qu'il n'y ait un script quelque part qui redéfinisse
> > DISPLAY (ce qu'il ne faut pas faire, ssh le faisant très bien tout seul) :
> 
> L'erreur affichée a toujours été : "cannot open display:
> localhost:10.0".

Mais cela n'a rien à voir avec ma question. Je la reformule. Y a-t-il,
sur la machine distante, un fichier de configuration, genre .profile
ou .zshrc, qui définit explicitement la variable d'environnement
DISPLAY ? Cela pourrait expliquer le problème.

> > Difficile à dire, comme vous n'avez pas fait de 'ssh -v' (qui
> > permettrait de voir le problème) :
> 
> Mais si, toutes mes requêtes SSH contenaient évidemment le "-v",

J'ai relu la totalité du fil de discussion, et je ne vois pas une
seule fois la sortie de la commande 'ssh -v'. Essayer de trouver la
cause du problème dans ces conditions, c'est comme déboguer un
logiciel dont on n'a pas les sources. C'est possible, mais c'est plus
dur.

> et X11Forwarding (serveur) était à "yes" dès le départ.

Je suis sceptique, puisqu'on n'a pas la sortie de 'ssh -v', et que
vous ne dites pas comment vous avez vérifié ce point (dans
sshd_config ? Dans ~/.ssh/config ?)

> Ce point d'un serveur X à lancer, sur le serveur SSH et/ou le
> client,

Je maintiens qu'une bonne partie du problème vient de ce que vous
n'utilisez pas la bonne terminologie. Notamment, "client" ou "serveur"
tout court, sans indication du protocole derrière ("serveur X",
"client HTTP") n'a pas de sens (on n'est pas "client" ou "serveur"
dans l'absolu, on l'est pour un certain protocole, et même pour une
session particulière), et ne fait qu'aggraver la confusion.

> Le sujet reste non résolu pour moi.

Parce qu'on manque de données.

Re: Lancer une appli graphique en ssh : ça s'améliore

[ajh-valmer]

> Ne peut-on arrêter cette polémique ridicule ? :
> Ok, tu as raison, fermons le ban…

Non, c'est trop facile !

Les personnes intéressées par le sujet n'ont pas la solution.

Tout d'abord, pourquoi je reçois ce mail ci-dessous 3 fois,
un seul sur la ML suffit, sinon à quoi sert le principe d'une mailing-liste ?
Je l'ai exprimé plusieurs fois et ça continue toujours de la part de certains.

On Wednesday 22 April 2020 10:38:29 S. Bortzmeyer wrote:
> > > (au milieu des énormités lues dans ce fil),
> > > Tout ce fil de discussion est à jeter à la poubelle :
> > Quelles énormités... ?  Pourquoi ?
> 
> > Tu ne les indiques pas :
> Faux (cf. ma réponse à Pierre Malard) :

> > et ni même une piste de solution :
> Faux encore (la solution est de ne pas utiliser xhost du tout, ssh
> marche sans lui) :

> > C'est un problème de n° de display :
> Non. À moins qu'il n'y ait un script quelque part qui redéfinisse
> DISPLAY (ce qu'il ne faut pas faire, ssh le faisant très bien tout seul) :

L'erreur affichée a toujours été : "cannot open display: localhost:10.0".
Alors, que se passe t-il avec le display ?  Peux tu l'exprimer ?

In fine : tu as simplement indiqué ce qu'il ne fallait pas faire, 
mais pas ce qu'il fallait faire.

> Difficile à dire, comme vous n'avez pas fait de 'ssh -v' (qui
> permettrait de voir le problème) :

Mais si, toutes mes requêtes SSH contenaient évidemment le "-v",
et X11Forwarding (serveur) était à "yes" dès le départ.

> > Aucun tuto ne dit s'il faut lancer le serveur X sur le serveur ? :

> Je pense surtout que votre terminologie est défaillante.
> Sur la machine locale (celle que vous avez sous les yeux et que vous
> touchez), il faut un serveur X, pour piloter l'écran :
> Sur la machine distante (celle qu'on indique en argument à ssh), il ne
> faut pas de serveur X mais un client X (des bibliothèques qui sont
> incluses dans Debian, par exemple 'apt-cache show PAQUETAGE' montre
> qu'un programme graphique dépend de X).

Ce point d'un serveur X à lancer, sur le serveur SSH et/ou le client,
n'a jamais été exprimé clairement, la défaillance est là.
Je ne l'ai pas vu dans ton précédent mail.

Bref, je reste sur ma faim, quelquesoit le serveur X lancé,
sur le client et/ou le serveur, je reçois invariablement :
"cannot open display: localhost:10.0".

Le sujet reste non résolu pour moi.

Bon confinement à tous.

Re: Lancer une appli graphique en ssh : ça s'améliore

[Pierre Malard]

Ne peut-on arrêter cette polémique ridicule ?

Ok, tu as raison, fermons le ban…

> Le 22 avr. 2020 à 10:39, Stephane Bortzmeyer  a écrit :
> 
> On Sun, Apr 19, 2020 at 10:10:53AM +0200,
> Pierre Malard  wrote
> a message of 100 lines which said:
> 
>> Sauf que, avant d’être méprisant et sentencieux on peut aussi être
>> constructif et … pédagogue.
> 
> Quand quelqu'un donne des conseils absurdes et dangereux, il n'y a
> aucune raison d'être patient. Il est normal de crier stop.

--
Pierre Malard

 Fraternité :
Elle disparaît de plus en plus devant l’idéologie ultra-libérale;
la solidarité.
  Egalité :
Les lobbies, autrefois appelés corporatisme et combattu par
la révolution, lui taillent des croupières en influant de plus
en plus les lois et l'esprit des lois (école, assurance, chasse, allocs, 
...)
  Liberté :
Que représente t'elle sans ses corollaires ? Une vue à
court terme en oubliant nos enfants ?

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Lancer une appli graphique en ssh : ça s'améliore

[Stephane Bortzmeyer]

On Sat, Apr 18, 2020 at 04:46:47PM +0200,
 ajh-valmer  wrote 
 a message of 31 lines which said:

> > (au milieu des énormités lues dans ce fil),
> > Tout ce fil de discussion est à jeter à la poubelle :
> Quelles énormités... ?  Pourquoi ?

> 
> Tu ne les indiques pas

Faux (cf. ma réponse à Pierre Malard)

> et ni même une piste de solution.

Faux encore (la solution est de ne pas utiliser xhost du tout, ssh
marche sans lui)

> C'est un problème de n° de display.

Non. À moins qu'il n'y ait un script quelque part qui redéfinisse
DISPLAY (ce qu'il ne faut pas faire, ssh le faisant très bien tout seul).

Difficile à dire, comme vous n'avez pas fait de 'ssh -v' (qui
permettrait de voir le problème).

> Aucun tuto ne dit s'il faut lancer le serveur X sur le serveur ?

Je pense surtout que votre terminologie est défaillante.

Sur la machine locale (celle que vous avez sous les yeux et que vous
touchez), il faut un serveur X, pour piloter l'écran.

Sur la machine distante (celle qu'on indique en argument à ssh), il ne
faut pas de serveur X mais un client X (des bibliothèques qui sont
incluses dans Debian, par exemple 'apt-cache show PAQUETAGE' montre
qu'un programme graphique dépend de X).

Re: Lancer une appli graphique en ssh : ça s'améliore

[Stephane Bortzmeyer]

On Sun, Apr 19, 2020 at 10:10:53AM +0200,
 Pierre Malard  wrote 
 a message of 100 lines which said:

> Sauf que, avant d’être méprisant et sentencieux on peut aussi être
> constructif et … pédagogue.

Quand quelqu'un donne des conseils absurdes et dangereux, il n'y a
aucune raison d'être patient. Il est normal de crier stop.

système de fichier crypté (sur disque dur local) partageant la clef avec SSH

[Basile Starynkevitch]

Bonjour la liste,


Je cherche un système de fichier crypté sur une partition vierge d'un 
disque local (d'un portable récent, voir ceci 
<https://unix.stackexchange.com/q/564066/50557>) dont la clef serait 
partagée avec SSH.



Autrement dit, après un ssh-add je souhaiterais avoir accès à ce système 
de fichier.



Bien sûr, il y a sshfs <https://doc.ubuntu-fr.org/sshfs> configuré en 
local, mais il y a-t-il d'autres solutions?


Techniquement mon portable est sous Ubuntu 19.10, mais s'il fallait y 
installer Debian/Sid (ou Debian/Buster), je pourrais le faire.



Librement


Basile Starynkevitch - http://starynkevitch.net/Basile/
Bourg La Reine, France  
opinions are only mine - les opinions sont seulement miennes